Ideas on Code Strategies

This past week I have spent time thinking on some of the best applications I have built, and some of the “neediest” applications I have built. Some of them are in both columns. And I am sure this is the case with most developers. Some times, we get to be part of a major project, and get the best possible ideas, and then BAM, a product is released. After patting ourselves on the back and thinking of how great it is, we find special “features” that require updates or bug fixes. Had we just followed some simple steps during the build phases, I am sure we could have prevented that.

In today’s software development world, many phrases are thrown out there and used. We have SDLC, Agile, Waterfall, Extreme, Scrum, Feature Driven, Test Driven, etc. All of which are great when actually used. But how many places that use those terms are actually doing those practices? There seems to be a bigger practice out there, one that is used more frequently than anyone dares admit. This is a practice I refer to as the Atomic Development Cycle (ADC). I am sure we all have done this, either in its entirety or used many pieces of this.

Characteristics of the ADC can cover a wide range that seem reasonable and responsible, but fall far from it. The project is defined in generalities, and possibly some specifics. The design has been kicked around, maybe even pre-approved. The main data has been identified but not analyzed. The use cases have been discussed, not documented. Timelines are unbelievably tight but manageable. Code is dived into, and testing plans not thought of. The final product looks brilliant seems like flash of light. And it usually is just that, a flash of light, and not sustained. Soon, bugs start appearing. Enhancements require more fixing than actual functional coding. The database design turns out to be too strict and not flexible to the changes, so now Db design changed force more testing and bug fixes. Soon, band-aids are applied to the app, and the app is wrapped up in kluge code and an embarrassment. But since the business saw the initial brilliance, it still wants to use it, and now you are forced to go back, triage and rebuild.

Some projects force my hand into doing this, Other times, it could just be laziness or lack of caring about a personal project that would force my hand in this. With this new year, I need to be better about this. I know better. I know that not all apps are going to work well out of the box forever. But I do know that apps that follow a structured process that ensure the proper framework is in place will succeed more than the ones slopped together. Understanding the proper requirements of the application, even if they do change, is important. Getting the Database in order is tantamount to success. Designing the code is another gigantic step in the right direction. I need to be better and not let this get out of hand.

Yes, the ADC may work in some instances. And yes, they may provide for some awe-inspiring, mind blowing apps. But just like the atomic bombs, they may look brilliant for a short time, but the devastation they leave behind is never worth it.