Formalizing The Process

As mentioned in the previous post, software development is a create process craving for freedom, but at the same time should the freedom be limited. In this post I will go a step further and look at why a developer should ‘restrict’ himself, take away a part of his freedom. This holds both if he is working alone, or in a team.

The kind of restriction I am talking about is formalizing the entire software development process. After all software development is still a process and to control and monitor a process we need to have a ‘path’ specified for the process. Only then can we find out what went wrong and where improvements are possible.

If you use an agile method, such as SCRUM, you will likely already have a clear process. This is resembled by all the stages an issue has to go through from being submitted until being resolved. This often includes steps as ‘In Development’, ‘In Review’ and ‘In Testing’, what happens at each of these phases can however vary a lot and it is important to define the responsibilities of each of them. By doing so you will be ‘formalizing’ the process.

By formalizing I mean specifying what should be done during each phase, but not in such a way that there is no freedom left. A simple checklist should do, going beyond a simple checklist will force too much restrictions upon a developer and will make him feel like he is just executing orders.

Why do we need to formalize the process? It all comes down to quality, if developers are allowed to do whatever they want or not, it is hard to track down where things went wrong. Besides that it is also helpful as people (even developers) tend to forget, or skip when there is a lot of pressure to deliver something.

What should be formalized? This depends on how the organization works, team structure, kind of software and many more factors. But I do give a list of things that I can think of and are very general.

  1. Did you do static code analysis?
  2. Is the code readable?
  3. Is there enough documentation (for users)?
  4. Are there tests? And do they pass?
  5. Do all the old tests still pass?

Some developers might object to such a formalization, and I have heard the most ridiculous reasons going from: “We are all intelligent enough” to “We already have code conventions, isn’t that enough restrictions?”. True intelligent people acknowledge they are not perfect, after all, if you are really perfect then you don’t ever forget something and you never ever write bugs, which is impossible.

Though formalizing the process does restrict freedom in some way, it should be nothing more than just a reminder of common sense. All the things that have to be done in the process (and are formalized) should be things any normal person can agree on why they have to be done. If this is not the case, it should be made clear why it is required. By doing this developers won’t see it as restrictions but as a checklist to make sure they deliver the best product they can.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.