Light methodologies rely on quickly iterative design cycles to fulfill their promise of rapid development and smart solutions. But how quick can you be if you’re using plodding design tools or wading through reams of cumbersome, overwrought code?
A key aspect of light methodologies is their need for simplicity. All light methodologies value simplicity over complexity whenever possible. Use that one tool that satisfies 80 percent of your needs instead of adopting three tools to cover 100 percent of your wish list. If you can use 50 lines of simple code to substitute for 25 lines of elegant code that only you can understand, go with the 50 lines. When you design an application, do it as cleanly and simply as possible.
Simple design and coding
The overall design of your application needs to be simple and flexible. Avoid design decisions that are perfect for your first iterations but then don’t allow you to add features and functions in later iterations. This can happen if you tie program components too closely together, instead of maintaining a level of independence.
You also don’t want to overengineer a solution. If you’re building 100 reports for your application, you probably need some sort of user library structure to keep track of the reports and what they do. But if your solution requires just 10 reports, drop the library.
Your code needs to be simple to review and to understand by others who follow you. If you look at the total life cycle of an application, only about 20 percent of cost is spent during the development phase. The remaining 80 percent is spent in the support and maintenance phases. If you build a no-frills application, the code might run in production for 10 years or more. Simple and straightforward code written up front allows easier learning curves, error fixes, and enhancements over the entire life cycle.
Simple program documentation
Writing documentation is the bane of many programmers. First of all, many programmers are great with computer languages but aren’t very strong with English. Secondly, programmers tend to write their comments and notes for themselves, not someone else who will need to understand them.
Light methodologies tend to advocate essential documentation, but no more. This minimalist approach recognizes the inherent limitations of documentation.
Take program documentation, for instance. If you‘re trying to track down problems in code, you’re not going to be able to find the problem in a programmer’s manual. The only place you’ll find the bug is in the code itself. Even if the customer asks you to investigate how a feature works, you typically can’t rely on an external programmer’s manual. The only way to know for sure is to check the code. So having a stand-alone programmer’s manual that describes the code probably doesn’t make sense.
On the other hand, the code itself should have plenty of comments. These comments shouldn’t reflect the obvious but instead should point out creative techniques or describe major sections of code that enable certain features and functions.
Programmers might also be asked to assist with users’ manuals and help features. Again, you should convey a basic understanding to others that are not involved in the project. In many cases, large users' manuals are created but only certain parts are ever referred to again. Work with your customer to anticipate the basic documentation needed and build at that level. The more extravagant the documentation, the more content will never be referred to again.
Part 5 of 5
Check out the rest of Tom Mochal’s series on light development methodologies.
- "A light discussion on light methodologies"
- "Light processes keep development cycles short and sweet"
- "Light methodologies demand full customer involvement"
- "Light methodologies make the most of team members’ time and skill"
All of us have heard about the 80/20 rule. Perhaps 80 percent of an application’s business logic can be coded in 20 percent of the total development and testing time. Light methodologies rely on users really accepting the 80/20 philosophy. It’s true that you don’t want any sequence of user logic to result in errors or an application failure. However, you may not need to create an elegant recovery strategy for every possible input combination. For obscure error combinations, maybe it’s acceptable to simply point out to users that they have made a mistake and need to start the transaction again.
In the same way, users sometimes ask for every feature and function that they might possibly need over time. The better approach is to look at must-have requirements and then build the application to those specifications. In many cases, extra features will not be utilized often. If some borderline features do prove to be absolutely necessary, they can be added into future iterations or as enhancements after the project is complete.
Rank priorities as low, medium, and high, and then agree that no low-priority work will be incorporated in the project. You can note the requirement to show that it was considered, but there’s always something more important to work on than a speculative feature that will not be needed when the application goes live. Again, if the requirement is important, write it down, but as an item to be considered later, not to work on at this time.
It’s as easy as you make it
Light methodologies tend to falter when applied to very large and very complex projects, which require more rigor and structure. On the other hand, sometimes we make projects larger and more complex than they need to be. When you are working with your customer on a development project, try to always think simply. Think about implementing the basic requirements, in a simplistic manner, rather than trying to create a solution that meets 120 percent of the business needs. You may have heard the saying that “better is the enemy of good.” You can always make things better and better, but your sponsor will be more than happy with a good solution that is delivered on time and on schedule.
What is your take on light methodologies? Drop us an e-mail or post a comment below.