I’ve had software development folks tell me that the “just do it” approach is a valid lifecycle model for SW development.  In their context, this means writing the code based on limited marketing and design information and then backfilling the requirements and design specifications to describe what was done.  They claim that all the requirements can never be known and written down at the beginning of a project, so marketing and upper management only know what they want when they see it.  (How sad to think that educated and intelligent people can’t find the words to express their thoughts and desires).  They claim that SW design evolves as a result of trial and error, and the best designs are based on the “ah-ha” moments that come out of troubleshooting problems.  (I might counter that requirements review and static analysis will yield these “ah-ha” moments quicker and with less pain).  But let’s see why some people may feel this “just do it” approach has any merits.

If this approach helps at all, it may be due to getting SOMETHING done, even if it’s not perfect.  This can help solve the “paralysis by analysis” dilemma that plagues many development groups.  It often feels good to know that you’ve accomplished something.  In a fairly short time, you can find out if what you’ve done is worth continuing or if it should be discarded.  But there is a risk to keep doing things without recording what was done, or why certain paths were not selected.  Also, the number of SW people on any given project is generally greater today than years ago.  Without a set of reviewed and approved specifications, it is difficult for all team members to understand what is already done and what has yet to be done.  Maybe a 1 or 2-person project could keep things straight for a while, but eventually someone else may need to maintain the code.  To meet the IEC 61508 requirements, you need the documentation.

Early in my career, I unknowingly used such a “just do it” approach to write the code, and complete my projects.  It was perhaps the only way I knew to work.  Software development process, at least on embedded development, was immature.  Project schedules seemed woefully optimistic and end dates were exceeded more times than not.  And I understand the euphoric feeling when something actually works.  But I also know the pain of trying to fix field problems of products where the original developers were no longer available.

Getting something done is often better than getting nothing done.  But getting something done more effectively is better than using a seat-of-your-pants approach and it will pay off in the long run.