Sunday, December 23, 2012

Functional and Technical spec in software design

      I started reading +Joel Spolsky's blog pretty heavily. I'm reading his old posts from 2000s. I'm pretty sure most of you are familiar with his blog - it's kinda famous in software development world.
I'm reading 3-5 posts a day. I don't agree with some of this thoughts (he didn't agree with some of them too as time goes :) ), but most of them are pretty bright.

      One of the ideas, that I'm trying to employ is technical writing - guess what, this blog was made for this - to practice writing in English on technical topics. But because of my laziness I wasn't doing much here. So that's should change in next month or so.

      Another thing, that I'm trying to get used to - is functional specs, as he calls them. A document that describes feature - essentially document that will help all people involved in software development process to get understanding how feature should work and what should be done for this.

      But functional spec, as Joel points out - is view from user's point. And it can be written by program manager - person who is not a developer, but more list a marketing\product development kind of person.

      On the other hand, in complicated situations - like developing new product or producing a large feature (more like a feature set) - when implementation is not clear - there should be a technical spec. Or functional spec should incorporate this information. 

      The purpose of that is to think about design/implementation and future obstacles:

A software design is simply one of several ways to force yourself to think through the entire problem before attempting to solve it. Skilled programmers use different techniques to this end: some write a first version and throw it away, some write extensive manual pages or design documents, others fill out a code template where every requirement is identified and assigned to a specific function or comment. For example, in Berkeley DB, we created a complete set of Unix-style manual pages for the access methods and underlying components before writing any code. Regardless of the technique used, it's difficult to think clearly about program architecture after code debugging begins, not to mention that large architectural changes often waste previous debugging effort. Software architecture requires a different mind set from debugging code, and the architecture you have when you begin debugging is usually the architecture you'll deliver in that release.
      This is Design Lesson 2 from history of Berkeley DB. Check it out - nice article about history of development pretty complicated system.