Tuesday, September 20, 2011
software engineering notes #200911: write design documents, and be explicit.
The first professional app I designed and implemented was not a disaster, but it certainly felt like one.
I was given another app that was written in a language that has reached its end of life, and was told to rewrite a new app that is similar, and that it could be compiled in 64-bit.
What I did not expect was that my manager kept doing the same thing to me: he would come into my office, look at what I have done, and told me to change things around or add something according to his new idea of the hour. Initially I had some kind of design, but that was soon thrown out because of the constantly changing requirements and deadlines.
Later on, I picked up some better processes.
To avoid writing something only to be told to do something else, first write down what you are going to do. After you have written things down, people comment on it, discuss about it, argue about it, change it, whatever. At the end, all the decisions are made on paper, and people understood the project well. People can now talk about it, divide the work up, write tests against it, refer back to it in the future, etc.
Regarding the point about making decisions, the decisions that aren't written down explicitly are being decided anyway, but they are done implicitly, usually by the developer as he is writing the code. Now, if you are his manager, would you prefer him to come and ask you, or have him make his own decision? What if he doesn't know what to do, but doesn't ask you about it either?
It is good to take the time to write down the requirements and designs. It gives you time to think through the problem, and it helps communication greatly. The time and effort you put up front for the documentation is well invested.
I was given another app that was written in a language that has reached its end of life, and was told to rewrite a new app that is similar, and that it could be compiled in 64-bit.
What I did not expect was that my manager kept doing the same thing to me: he would come into my office, look at what I have done, and told me to change things around or add something according to his new idea of the hour. Initially I had some kind of design, but that was soon thrown out because of the constantly changing requirements and deadlines.
Later on, I picked up some better processes.
To avoid writing something only to be told to do something else, first write down what you are going to do. After you have written things down, people comment on it, discuss about it, argue about it, change it, whatever. At the end, all the decisions are made on paper, and people understood the project well. People can now talk about it, divide the work up, write tests against it, refer back to it in the future, etc.
Regarding the point about making decisions, the decisions that aren't written down explicitly are being decided anyway, but they are done implicitly, usually by the developer as he is writing the code. Now, if you are his manager, would you prefer him to come and ask you, or have him make his own decision? What if he doesn't know what to do, but doesn't ask you about it either?
It is good to take the time to write down the requirements and designs. It gives you time to think through the problem, and it helps communication greatly. The time and effort you put up front for the documentation is well invested.
Friday, September 2, 2011
project management notes #02091: define precise goals
Have you ever been told by your manager to get something to work?
If it was a well known problem or a simple one, usually there won't be any complications. On the other hand, when it is a complex problem involving many variables, simply 'get it to work' does not suffice.
Define goals that leads to the solution. They need to be small and precise ones. This allows measuring of progress and makes distributing work easier.
If it was a well known problem or a simple one, usually there won't be any complications. On the other hand, when it is a complex problem involving many variables, simply 'get it to work' does not suffice.
Define goals that leads to the solution. They need to be small and precise ones. This allows measuring of progress and makes distributing work easier.
Subscribe to:
Posts (Atom)