I sometimes get amazed on how easier it gets to write the software given that I have its documentation written down.
Now that I am writing this stuff, it looks obvious that it is true, but back when I was struggling to implement a HTML utilities library for myself without its documentation, writting one prior to writting its source code made everything much easier.
I think this is related to having a precise software specification prior to its implementaiton process.
Obviously, in most cases, it is not even possible to document the whole software before having it, but it turns out that a complete and flawless documentation before hand isn’t needed. It is also pointless. Software design will change during the implementation process. However, you’ll still benefit from having a clear image of what you want to create.
In talking to some people at irc.freenode.com, it was somewhat common to have people starting to develop something using what is called OOP features, such as C++/Java classes. But, later they would just go back to some simpler language such as Python, Perl or Shell Script, sometimes, even C (I still, rarely, write some command line applications in C). Many GNU programmers tend to do pretty much everything in either C or some Lisp dialect (mainly emacs lisp).
Sometimes, your initial idea of what the software is going to need is not right. Some other times, you want to use a programming technique just because you think it is the better one (many people has that belief for OOP), or just because you like it (that is me for functional programming).
If, in the middle of the implementation process, you decide to change some interface, or some other piece of design, then things can get messier since the new design and the old design may confuse you (this just happened to me, by the way).
You may be tempted to believe that the design changes are small, and you’d be able to have two clear separated images of the older and the newer design, but it ends up being a very error prone situation. I suggest writing down all versions of the software design, as small documentation documents, as you go along with the implementation process.
Some documents out there, and people, suggest that you should design the whole software before hand, and just then implement it. I don’t agree with that idea. It looks too idealistic, and it’d make the whole software development process much slower. Sometimes, it is just better to just get some code written to see how things will be run by a computer.
An example of that is the discussion of bottom up versus top down design. I’ve heard people saying (very few) say that top down design is worthless. But my own experience says that top down design is very efficient for finding out how to do create your bottom up design, which is essential.
It is very hard to guess before hand what is the language you should build so that the implementation process of a software specification becomes natural. One way to get the feeling for which is this language is to actually start writing the software in top down design. Separate the major parts, and, as you write the software, you’ll feel the need for the layer of abstractions that would be very convenient to be had so to write the program.
In the beginning of On Lisp, this “process” is explained: how writting a software should give you the feeling “Gee, it really would be good to have SUCH AND SUCH feature in here.”, or “What I really need is THIS FEATURE.”. I don’t believe you can get this kind of insight without actually try to write the software.
There is a series of videos on JavaScript, by Douglas Crockford. The first one of the series is a speech he gives telling part of the story of computers and software. In that video, he told that functions, at first, were good for performance (space-wise), since your program text could be smaller given that it would have a given set of instructions repeated many times in it. After that, functions became means for modularity.
But later, people started to use functions in a different way. He tells that people started to think like “Which are the functions I have to write so that implementing my software becomes easier?”, which is the nature of bottom up design. And the only actual way, that I am aware of, to effectively answer that question is to try to write the software, and see how the base language gets in your way during the implementation process.
I think I got my point across. This post is getting pretty big. Bye now =).
Recent Comments