I’ve been thinking of the best way to develop under these circumstances. Unless we mutiny and refuse to build the software, my teammates and I must find ways to cut corners, without ending up producing a bug ridden, un-maintainable, useless piece of sh…software.
I believe developing under these circumstances will not only produce poor results across every standard that we judge software by, but also be more expensive. Maintenance costs make up most of the expense of many systems. In general, the higher the quality produced during development, the lower the maintenance costs, and the lower the total cost of the system.
Usually changes to a system decrease its overall quality. The quality starts at its peak when the system is first created, and degrades overtime as more and more changes are made. That isn’t always the case and there are many other contributing factors, but it has been my experience it’s the general trend of many software systems.
It doesn’t have to happen. Usually the approach during maintenance is to touch as little as possible. If however the maintenance programmers take the attitude “I’m going to improve the code every time I touch it,” then the trend is reversed. Maintenance is more expensive initially, but doesn’t degrade the quality. As a result, it should make the system cheaper overall by extending the life of the system.
The best approach when cutting corners during development is to push the work off until maintenance. This requires the maintainers take the latter attitude.
There are 2 problems with this. First, the maintainers rarely take the attitude to improve the quality of the system, and their managers would rarely support it (budget wise) if they did. The second problem is that it is always more time consuming and expensive to make changes in the maintenance phase then it is in the development phase.
In the best of circumstances, cutting corners during development is like taking a loan with a huge interest rate to be paid during maintenance. Default on the loan and the system goes bankrupt.
Design
Always think before you code. That part of design hasn’t changed.
The goal is to be quick, without being too dirty. What is “too dirty”? That is a judgment call made on a case-by-case basis.
As with all software projects, every design principle is useful, but there are a few that deserves special mention:
KISS (Keep It Simple Stupid): Remember the goal is to fix many of the problems during maintenance. The simpler the code is the easier it will be to do so.
DRY (Don’t Repeat Yourself): Rewriting the same code over and over is not only bad design, but can also be time consuming. However, sometimes cut and paste can be quicker and simpler. Use your own judgment on how and when to apply this principle.
Encapsulation: Encapsulation is always important, but much more in systems developed quickly. It is inevitable that mistakes and lapses in judgment will be made. The result is likely to be a mess. The more isolated that mess is, the less harm it can do, and the easier it will be to fix. Lack of adequate encapsulation will likely mean a failed project.
Testing
Unit testing is essential. If it is done well it can save time, especially during later phases of the project. It will also make cleaning up the code during maintenance much easier and cheaper. It’s well worth the initial effort.
Don’t try to hit some magic code coverage number. Instead focus on tests that give the biggest bang for the buck. Make sure the most complex logic is isolated and test them thoroughly. It is likely most bugs and changes will be in those classes.
Don’t write a test class for every class. Instead group classes together and test them as a single unit. There is a fine line between unit and integration tests. It is judgment call as to how close to that line is appropriate. Another option is to forgo unit testing in favor of small integration tests.
Consider not testing some boundaries. It can be very time consuming to unit test code that interacts with frameworks (especially web frameworks). Instead isolate that code as much as possible and keep it simple. Delegate all responsibilities to other classes that are more testable.
Bugs
Even under the most ideal circumstances, developing code quickly will result in many bugs. How do you deal with them when there is not adequate time?
Finding all bugs can be time consuming. It many cases you should trust your testers to find your bugs. All changes should be system tested before passing to the QA team, but minor changes do not always warrant a full system test. Again use your best judgment.
Second, not all bugs are created equal. There are many bugs that can be put off. Such bugs can be time consuming to fix as well. By a show of hands how many of you web developers have spent several hours or more messing with the CSS to get an element to align exactly the way you want it?
Scope
If you hired a contractor for $5000 to build a deck, and through no fault of his own, ran out of money after completing 90% of it, what would you do? Most people would pay the extra money to finish it. Most business owners would do the same for their software.
Don’t feel you have to do whatever it takes to deliver on time. In general it is more important to deliver adequate (if not top notch) quality late, then really poor software on time.
Expectations
Quickly developed software will inevitably lead to a poorer user experience and higher maintenance costs. It is important the project stakeholders are well informed of the trade offs being made by the budget and timelines. The worst outcome is to push a development staff hard for months to deliver a poor quality product and then get told, “If we had known this is what was going to happen we would have given you more time”.
*ails
The grails and rails frameworks have the potential to change the rules entirely. The above was written under the assumption software has a large up front cost, and is under maintenance for a long time. What would happen if development of small and medium sized web applications become so quick and cheap that it becomes advantageous to rewrite it every couple of years?
At the beginning of the post I mentioned how the quality of software starts out at its highest level and degrades over time. If the system is going to be rewritten in a couple of years, then the quality only has to be good enough to last until then. It may be better to aim for quicker development with lower (but still adequate) quality.
There are still a lot of question marks about how grails and rails will be utilized in the corporate world, and the impact that will have on software development. The only thing I’m sure of at this point is that there will be an impact.
Conclusion
I have yet to finish the project I’m on. One of the reasons I’m putting these ideas out there now is to elicit useful feedback.
Feel free to tell me your ideas and point to any study that contradicts or confirms anything I mentioned above. Is there anything that I missed? Is there anything that I got dead wrong? Also leave your rating, either +1 Joss Whedon (good) or +1 Aaron Spelling (bad).
The project sounds like a train wreck about to happen. I particularly found your section on "Expectation" interesting. If fear your "worst outcome" may come to pass. Was any serious consideration given to the mutiny you alluded to in the first paragraph?
ReplyDeletePlease follow-up with updates on how the success or failure of this project.