The philosophy of a prototype

Prototypes are something every software developer comes across in his lifetime. Usually quite informal in the early stages of their career by coding by the trail-and-error-pattern where every iteration can be seen as a prototype for the next. Later on, with projects getting bigger, it is most likely that the programmer starts to use prototypes more systematically. Some even learn to formalize them and use them in a professional way. In the end, software developers can be categorized in two groups:

  1. Those who see prototypes as a build-product in early stages of software development which improves project quality and resource planning by testing certain aspects and/or try new methods to create the product and which must be thrown away before the actual project is started to reach best possible product quality
  2. Those who do not care so much about all these words and just like to code straight away

From how I wrote this, you might get an idea which philosophy of those both I personally prefer. But I’m not one of those who take the proceeding too seriously. I regard the prototype as a piece of software which I use to analyze and gain information to compensate missing knowledge. This might be because I want to learn about a new technology or because I want to try new tools. Or because I never worked on a similar project before – which should be quite usual for a ambitious software developer. But I do not regard it necessary to create a prototype for really every project I work on. Sometimes it is possible to just determine one.

As the experience of the engineer increases, it is sometimes possible to find old projects which just can be looked at from another new point at view. Or it is possible to find another project which fulfills similar aspects to what one intends to work on. This approach however requires a highly skilled engineer as it is a difficult task to gain knowledge from a foreign codebase. Especially if the requirements or the design of the foreign project was not documented. This is sadly quite often the case in available open-source projects. In this case the gain of knowledge is close to zero.

Planning the planning

In my last post I postulated 18 points of inevitable steps in software development. Now I want to explain some of them. Let’s start on the top

First and – in my eyes – the one most important point is to organize the project evaluation itself. This might sound trivial but is most likely to get forgotten in the whole process. The reasons for that are diverse but one can classify them in two categories: other-directed projects and self-directed projects. An example for the first category are customer-ordered-projects whereas the latter could be normal product development e.g. implementation of a new major feature. In the first case, planning the planning is often omitted as a customer offers his own ideas on how things work. In the second case almost the same is done by some higher-ranking management person. Why first listen to those who should do the work when you already have a phantasy of what will happen? Never confront illusions with reality seems to be the devise here.

Everyone involved with project planning knows this situation: The idea of what the result of the project might look like has just been vaguely, informal described and now you are asked “Tell me, how long would it take?”. And now you are asked to compete with an absurd small period of time without any ressource-planning being made. And no matter what you answer – you suck! The worst thing you might do is to give an answer which can me interpreted somehow as if it is possible. But usually you should have enough knowledge in this situation to give at least an time-table what to do until you could answer this question and how long it might take. This is 1. because you got this position somehow and 2. hopefully for a good reason.

I’ve heard and seen a couple of cases where the give timeframe until the project can seriously be evaluated was far beyond the absurd assumption made previously. In this case you can either

  1. try by ignoring that you do not have the slightest idea of what the result will look like
  2. you are convincing that the time is necessary and either worth or the project is doomed or
  3. quit the job

Most project managers decide for the first option. As a consequence software development is most often somewhat of gambling where you can only bet whether the current project is doomed or keeps being dissatisfying. Please note, that the latter options is the more favorable one. Sad enough.

A project plan frame

No one working in software development would doubt that project planning is necessary and important. But one may doubt that anyone knows how to do it. Actually I don’t remember someone ever telling me that a project plan worked out just fine. But I know a lot of stories on how project plans just failed inevitably. And before I post something about the my greatest failures in project planning – this might come later – I want to write about how to frame a project plan which respects the most important aspects from my point of view.

First I will draw an outline of the project:

  1. Set a timeframe for project evaluation
  2. Determine and formulate the goals of the project
  3. Create or determine an prototype
  4. Determine and formulate the gained cognitions
  5. Determine and formulate the positive and the negative aspects of the prototype
  6. Revisit the goals of the project
  7. Evaluate the project: time-constraints, resource-constraints, quality-constraints, expected results
  8. Sketch out a project design
  9. Build a sophisticated project infrastructure!
  10. Split the project into tasks and assign them explicitly
  11. Create the implementation
  12. Check wether implementation fulfills the project goals
  13. Mend the implementation
  14. Check wether implementation fulfills quality standards
  15. Improve the implementation
  16. Create Documentation for usage, administration, configuration and deployment
  17. Approve the results of the project
  18. Deliver or use the results and be happy with it

Yeah, I know there are about a gazillon of different models for projects plans out there. So why come up with a new – such informal – one? The reason is, that all of this points must be done at some point, no matter what the project plan layout looks like. Whether you are working in a scrum-like-pattern or with a fully elaborated derivation of the V-Model. So this is not an alternative model made by some who thinks he can easily reinvent everything because he likes to ignore textbooks. This is merely an enumeration of what is unavoidable in a software development process – and nevertheless most often done wrong!