In general terms, within larger organizations (e.g. corporate or government environments), there exists two broad approaches to "software development":
- Top-Down
- Bottom-Up
Top-Down
When you have the luxury of working in a structured team scenario, especially (possibly ONLY) when it consists of talented people that ALSO get along VERY well, you can take the time to plan and proceed in a logical manner. By this, I mean: gather requirements, assess the status quo against the desired outcome, determine gaps, resources, timelines, etc. And you may even have the luxury of dedicated project managers, program managers, developers, architects, test groups, test procedures, CMMI and all that.
This notion of planning ahead, designing everything methodically, testing and more testing, is all part of the "top-down" approach. This is the approach taught in schools, text books, lectures, and so on. It's admirable and difficult to find fault in this concept. But everything has potential drawbacks.
Bottom-Up
When you start coding within a short time of having an idea. When you are faced with crisis-mode problems that demand your full attention to solve using whatever tools you have at hand. When you don't have an elaborate structured environment to delegate tasks to. When like to create and evolve something, rather than plan it ahead. All of these reasons, and many more, often lead immediately into a "bottom-up" development process. Oftentimes this approach ends up at a crossroads with Top-Down ideals, where the developer(s) stops at 2.0 or 3.0 and decides to refactor, clean-up, and document everything. At this point, it often takes on a new direction that feels more like "top-down", even though it didn't start out that way.
So what's the best way to go? There is no "best way". There is only the "way" that works for your endeavors. Sure, logically speaking, it's hard to argue that with all the right pieces in place, that a "top-down" process isn't the better option. But a lot (repeat A LOT) of developers do not have such luxuries. And even more of them have personal leanings towards "bottom-up" because it suits their creative process. Is that wrong? Who knows.
I've worked in both camps for quite a bit of time. There are aspects of each I like and dislike. Sometimes I compare them to cooking with gas versus a wood fire. One is simpler to get going, the other has a nicer feel to it.
One subtle, often overlooked, yet serious drawback to the "top-down" approach is the timeline. With a more rigorous application of metric-oriented planning and execution comes a long duration (start to finish). While that may seem like an obvious cost risk, the other side of this (the part I propose as being "overlooked") is the budget window constraint. I've seen plenty of large-scale development projects fall to the cutting room floor because the timeline ran afoul of an ever-scrutinized budget. Many times it happens before any code has been written. Great ideas on paper, in a server shared folder, in SharePoint or some other repository, being hashed and vetted and showing immense promise, only to slide unknowingly under the falling axe of a budget cutback.
On the flip-side is the "bottom-up" approach. Sometimes viewed as "shooting from the hip" or "wild west show' approach. Get the code moving sooner and work out the kinks as they come up. Give and take with the end users. It is exciting to work in that fold. I much prefer meeting users face to face than sifting through survey reports, forum threads, and e-mails.
As Chris Curran states*:
"While Agile and CMMI can coexist, there are limits. Agile practices can normally function with CMMI levels 1 to 3 but are usually incompatible with the higher maturity levels 4 and 5. At CMMI levels 4 and 5, the intrusion of documentation into the development process over-formalizes Agile’s internal discipline and Agile ceases to be agile."Everything has limits obviously. You can't fit either of these approaches to every situation. There are many stories involving Facebook, Twitter and other recent major ideas where the nexus of their success was taking an unorthodox or hybrid approach to their entire inception and debut. Stop and think about every aspect of the way your are currently approaching software projects. Are there things you wish could be improved? Eliminated?
I need sleep. Cheers!
* "Are Agile and CMMI Compatible?" - http://www.ciodashboard.com/it-processes-and-methodologies/agile-cmmi-compatible/
No comments:
Post a Comment