Today I was updating one of our servers and naturally had a lot of free time while I waited for everything to download and install, so I started reading the 12 Steps to Better Code (also known as the Joel Test) article on the joelonsoftware blog.
The article makes some really good points about software development and how to do it right. From a programmers perspective it also gives you clues as to what to look for in a company you're potentially going to be working for.
After reading through the article I clicked on one of the links and found myself reading the full 4-part series about functional specifications. This article went into much more depth than the original 12 Steps to Better Code. The articles talked about why you need a spec, how to write a spec, who should write one and some general tips. This series of articles was timely for me personally due to our company having hired a new contractor which has taken on a project that's been dragging on for years at the company and as one of the first things he did was to write a functional specification and a technical specification (although the functional spec is actually referred to as the functional requirements, po-ta-to poh-ta-to). The amazing thing is that this first, relatively simple step has impressed the hell out of management. Finally they have a document that they can refer to to see the full functionality of the finished product and can start answering questions by clients as to what new features the program will have etc... They also look at the document and can get some more concrete idea of which stage the project is at, although this isn't the idea behind functional specifications. The other point that really hit home for me was about how by putting the functional and technical specifications in their respective documents, you minimize the interruptions to your own work, because instead of having management, marketing, Q&A people etc... bothering you with questions all day about how each part of the finished product will work, you can just refer them to the document. I would love it if I could answer all of the annoying questions I get throughout the day with "Have you read the spec?".
Overall, the message of "don't write a single line of code until you have a spec" is a powerful one, now if only I had the self-discipline to stick to it :)
The article makes some really good points about software development and how to do it right. From a programmers perspective it also gives you clues as to what to look for in a company you're potentially going to be working for.
After reading through the article I clicked on one of the links and found myself reading the full 4-part series about functional specifications. This article went into much more depth than the original 12 Steps to Better Code. The articles talked about why you need a spec, how to write a spec, who should write one and some general tips. This series of articles was timely for me personally due to our company having hired a new contractor which has taken on a project that's been dragging on for years at the company and as one of the first things he did was to write a functional specification and a technical specification (although the functional spec is actually referred to as the functional requirements, po-ta-to poh-ta-to). The amazing thing is that this first, relatively simple step has impressed the hell out of management. Finally they have a document that they can refer to to see the full functionality of the finished product and can start answering questions by clients as to what new features the program will have etc... They also look at the document and can get some more concrete idea of which stage the project is at, although this isn't the idea behind functional specifications. The other point that really hit home for me was about how by putting the functional and technical specifications in their respective documents, you minimize the interruptions to your own work, because instead of having management, marketing, Q&A people etc... bothering you with questions all day about how each part of the finished product will work, you can just refer them to the document. I would love it if I could answer all of the annoying questions I get throughout the day with "Have you read the spec?".
Overall, the message of "don't write a single line of code until you have a spec" is a powerful one, now if only I had the self-discipline to stick to it :)
