Observations In Effective Software Development - Part 3 – Functional and TechnicalSpecifications

This is the best, most optimal scenario that one could ever hope for... and that is all functional/UI and technical specifications are comprehensive and finalized before any programming or testing is started. This approach may sound like something straight out of a science fiction movie, and it very well may be what we can only dream about... however it would really be nice if this could be a reality when designing a software product. Since this has never been experienced by anyone that I know, including myself, I can only envision what this might entail.

Here are several “dreamlike” design and technical/functional specification scenarios:


1. Precise technical specifications. The bottom line on machine operating systems (PC and Mac), processor speeds, minimum memory, supported browsers and browser versions (for web), programming tools and language (not changing this in mid-development), preferred database, networks, etc. upon which the new software will work optimally would be most welcome. This would a great thing for everyone involved in the development process except for the fact that it is very difficult to predict what level of the most important technical aspects that an end user has in his/her computer setup. Even if these specs are decided in the beginning, testing the actual software on multiple platform combinations will reveal that system requirements do not always mesh well with what is going on out there in the real world. Oh, well.

2. Functional specs are clear as to what this product will do, plus screen mockups contain all final UI elements and graphics. Wow. Just reading that sentence was somewhat exciting. This scenario would take an awful lot of careful thought and planning well beyond the normal linear design process. Understanding what an end user will like about the way the software works (how it looks, functions and feels) and the general overall user-friendly aspects is most important in the development and ultimate deployment of successful software. Unfortunately, many designers and programmers have no clue as to what real people are able to deal with in the midst of using software. Development folks, from the concept phase, through the design phase, through programming and even quality assurance miss the mark when it comes to “ease of use” as they are often too self-absorbed in their own world and can't clearly see or understand that the software that they've placed so highly on a pedestal is really just a train wreck in slow motion. Realizing that business and user requirements may change many, many times throughout the development process is something that all dev teams should learn to accept to keep themselves from burning out or ending up in the mental ward.

3. Notes involving changes within the technical/functional specifications are clear to everyone involved. In making changes to specification documents, once again (this seems to be an ongoing, frustrating experience) any notes concerning changes to the product should be written precisely within the spec documents as to what the changes are and how the changes will be applied and also by whom. When change notes are scattered throughout a spec document that read like a cheap novel or sound like a conversation with a little kid at a playground, how can everyone really understand what is being changed and why? Keep the notes very clear, in the right spots, and realize that everyone in the development process benefits from solid terminology and communication.

4. Be realistic about product delivery deadlines. Yes, the business folks want it on that date... then development managers make promises that the software will be finished in that date. It is never finished on that date! I don't know of any software that has been “ready to go” on the date promised. Usually, when it gets down to the wire, there is a lot running around and panic which trickles down into the QA group to hurry up and test so the product can go out the door. More often than not, some massive defect is discovered the day before release and everyone goes nuts. There can be lots of finger-pointing when this occurs. Take a deep breath, fix the problem, get the release to the customers either on time or a few days later... relax. It is not the end of the world (maybe your job, but not the world).
Finally, we want to do great work because all of us in development take pride in what we do. Nothing is perfect and we are only human... and good software is simply a reflection of the good stuff in our human nature. Enjoy!

Read Part 2 of this three part article