I generally don’t like throwing quotes around to get a point across, but in this case I really like how it applies to the importance of documenting specifications in software development.
Engineers hate writing documents. And I don’t blame them. When you spend most of your time writing code and thinking in conditional statements, the last thing you want to do is open up Word and start writing specs (plus, that’s what we have product managers for!).
Any product requires careful analysis and information gathering before a single line of code is written. Surprisingly, in most projects the important stakeholders fail to answer one or all of the following questions:
- What is the application supposed to do?
- Who uses the application?
- How is it supposed to work?
Seems simple enough, right? Unfortunately, in software shops throughout the world, these questions are either ignored or hastily answered due to business pressures without spending the proper time discussing them among the role players of the team.
Here’s another quote for you: “Communication is what you get”. In other words, if the product is defined poorly then it will be developed poorly. How can you build a solid product if you don’t know exactly what it’s supposed to do? Defining what the product is (and isn’t) early on in the process will save time and money.
Regardless of what development methodology you use in your company, functional specifications should be obligatory in any product development scenario. You know what the application is supposed to do – but you also need to know how it’s supposed to do it. Functional specs give you that clarity early on. I like when product managers and developers (and invite the QA folks too!) get together at this stage because everyone’s on the same page as far as defining the product.
Sure, it may seem tedious. It may even seem excessive at times. However, proper specifications go a long way in ensuring the success of a project.
{"title": "technology, web, and life"} 