In the first installment of this four part series i essentially described how a good pure play software company operates and how the process or rather lack of process enabled much code to be created efficiently.

Compare this to any / most corporate environments. In this post i want to detail how software development happens in such a highly charged but disabled environments. This would also be a scary but educational read, for any un-initiated newbies who want to shift into such an environment but does not know what to expect.



After the *soft* in-principle decision to create a product is made, a master list of un-meet-able requirements are made. This is called the PRD, aka the Project Requirements Document.

Evaluate Requirements (1 month)

The managers task their teams to evaluate the PRD’s and come up with an estimated time and the doable items. The developers then go into an investigative mode, which again is loosely time bound. The developers come up with some arbitrary numbers after a rather relaxed period.

Estimation (1 hour – 1 day)

These numbers might get shortened or not depending on what effort, the manager arbitrarily decides the task is going to take. These numbers are informally communicated and then a rough priority of items that are doable is decided. Once this rough estimation is done someone gets tasked with creating the final list of items that will be taken up.

This phase takes a minimum of one month to an average of 2 months to complete.

SFS & SFS Review ( > 1 month)

The new task list is communicated in a new document called the SFS (system functional spec). During all this time meetings keep happenings twice a week between developers, and between development, management, program management and marketing to evaluate the concerns and overall progress.

The SFS once completed, is sent out for review where developers testers and anyone else remotely connected with the program take a dig at the rationale behind the features, the implications and so on. In short everything that be criticized will be criticized and the necessary concerns addressed and the items addressed in the document. This phase generally takes over a month to complete.

Executive Decision (2-4 weeks)

Once SFS has been reviewed over and over again, the program starts moving towards what is known as the EC (Execution Commit) which is a final go that the management has to get, from the upper echelons who ar ready to fund the program, for the features they are going to commit (aka promise) for the release.

As EC dates approach (and keep slipping), everyone goes into an overdrive to actually start more investigations into the features they are supposed to investigate and more issues crop up all over the place which in most likely hood, delays the EC plans. After a few number of delays, the SFS is finally frozen and the EC happens. Most of the SFS reviews and answers actually happens towards this period.

Committed ie Promised features have to be released without fail and hence everyone including managers make sure they consider the features only by adding liberal amount of buffer zones in their individual plans to make failure a low probability affair.

Design ( < 1 month)

Once EC is made, the design starts and this is when the actual troubles that a feature could run into are encountered (assuming the design is properly done). This might cause further delays as the issues are communicated back and forth to the management. The manager ensures that the teams actually do the designs by ensuring design review meetings happen. During this time the testing teams also start writing test cases, which the developers responsible for the modules are supposed to review and ok, apart from being reviewed by their own peers.

This phase can take from two to four weels overall. When controversies erupt, the design could be stretched to another two weeks.

Coding (2-3 months)

Once this phase is over, a hectic phase of coding starts, which is never more than 2-3 months on an average.

Developer Testing ( > 1 month)

Once this short affair is over development testing / integration testing etc starts which one or two of the developers do, to ensure things are fine before handing over the first cut of the product to the testing team.

During this phase not much happens with other developers and they sporadically fix bugs that appear off and on from their individual modules. The integrated pieces are handed over to the testing team, who now starts with each of their test cases and again report issues, which basically reflect the health of the system. Many of the issues come up during this phase and there occurs some or  more delays depending on how sloppy the coding was. One more release is then made within a short span of time addressing the issues discovered and finishing whatever features where unfinished from the first release.

This developer done testing and fixing phase takes well over a month totally.

Formal Testing (2 months)

Next the formal testing backed by formal test cases, starts in full earnest and a HOST of issues are discovered. The issues that consume the most amount of time are those that are related to system performance and this drags on quite a while until the test team is finally pressured into releasing the product and sweep some of the critical issues under the rug to at-least enabled a delayed shipping.

The no of emails that get sent during this phase and the meetings that occur between the test and the development teams, haggling over the actual nature of the issues observed are a tumulus affair. The entire testing phase takes up at least 1/3rd of the entire development time so you can imagine how long this affair drags.

In the meanwhile folks who have done their work fast and in a high quality manner can actually relax and drag their feet while the rest of the modules come up to speed. Most of the documentation effort starts towards the end of this phase and gets done in a few days time.

Release(1 month)

Once the entire affair is finished, the release is finally ok-d and then again starts a phase where the CD, licenses and other nitty gritty project management tasks are taken up and completed. Chalk up another month for this to finish.

Next Phase = Next Year

Once this is completed a new release and new PRD is announced which is circulated and the whole routine starts all over again. In my experience only 2 such phase ever gets completed in one year with a little bit of the next release overlapping into the same year.

Total amount of time spent coding = 2-3 months.

No matter how you look at this, there is no way a company that works on these lines can produce new code or new features that matter without a HUGE amount of time.  Some companies beats this by acquiring small companies regularly and customizes these well written products in ways it thinks suitable. Sometimes, the results are terrible but at times they are good. But hardware also folks can get away with this, since the over-priced items can always be packaged along with hardware solutions and sold to enterprise-y folks.

But never would a pure play software firm be able to survive on these lines. For that matter, never would an enterprise, be able to create quality products the same way that these other startup firms / pure play software firms do.

Key observations

  1. Coding happens for a max of four months an year
  2. Design happens for a maximum of 2-4 weeks an year and estimation takes only a day or an hour at the max.
  3. Documents are generated at each phase mostly as a way of keeping tabs
  4. Since these documents are control points, they need to be reviewed.
  5. Since review is work, and by reviewing you are agreeing to whatever is being said, no one individual is allowed to to do this. Instead the “team” does this, which forms a type of shared responsibility.
  6. Creating the SFS and design documents, reviewing the said documents, coding and some amount of formal testing is done by the engineers themselves.
  7. Since reviews are public and everyone reviews everyone else’s designs, there is a certain softness in the design comments. Maybe this applies only to India but its usually common to let pass docs that are even mediocre to a point due to a softness in cultural values that prevent one from being rude to one’s colleagues. No one but managers therefore can really therefore enforce design quality after a certain basic level.
  8. No formal time is allocated for design reviews

Implications of all these on the way an organization engaged in product development are many. But for this series, we are interested only on what the low levels of coding time imply. That brings us to the final post in this series.