Software Design in a Small Company

In large firms and corporations, the standardization of the software design process is commonplace. Smaller software companies sometimes fall prey to unorthodox processes for better or for worse. I have seen the latter in the current industry I work in. Smaller companies should have the flexibility of creating a software design process that meets their needs rather than following a rigid structure of larger companies. This flexibility also has its pitfalls.

The current software design process I have seen in my company is lax at best. At worst, it can be described as a complete lack of a process.

When a new addition to our software is to be created, the developers are told to jump right in. There is no requirements gathering or discussions with the end client. We generally call this rapid prototyping, but the prototype is useless. When the prototype is created by the developers (to the loose specifications of the project lead) it is shown the to clients. This prototype is generally non-working, with only the framework being in place. The clients and the project lead then evaluate the prototype. The usual outcome of this is to throw most or all of it away and start over. Additions to software come in as informal requests at any point in this ‘process’, and generally require the re-writing of already working portions of the software. This causes massive scope-creep and delays in the end product. In the end, the developers are told to push out a half working product to the clients for ‘testing’ purposes. The piece of software is then worked on and changed further. At some point, the decision comes from on high that the software is ‘good enough’ and left to its own devices.

I would completely overhaul this design ‘process’. First off, their needs to be a clear requirements gathering process before the first lines of code are ever written. This needs to be finalized with the clients to make sure that this is indeed what they want. Once that has been completed and finalized, the developers should be given free-reign on how to best fulfill these requirements. Scope creep would be kept to a minimum and the clients would receive the working product that they wanted.

Julian G Klimas