12-step program for the recovery of developers anonymous - Part 1

Back in the year 2000, Joel Spolsky wrote in his blog an article called ''12 steps to a better code''. 

programa OK

  1.     Do you use source control?

  2.     Can you make a build in one step?

  3.     Do you make daily builds?

  4.     Do you have a bug database?

  5.     Do you fix bugs before writing new code?

  6.     Do you have an up-to-date schedule?

  7.     Do you have a spec?

  8.     Do programmers have quiet working conditions?

  9.     Do you use the best tools money can buy?

  10.  Do you have testers?

  11.  Do new candidates write code during their interview?

  12.  Do you do hallway usability testing?

The idea is to respond with a simple yes or no to each question, and add one point if the answer is affirmative. Obviously, this is not meant to be a thorough exam of the failures of a team, but an attempt to provide a generic perspective focusing on the most important features.

According to the author, ''a score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help''.

This simple test aims at figuring out how effective a development team is. Although not its main goal, it can also be used for: evaluating what you can improve as a developer, measure the quality of the company where we want to work and consider different skills of the person when conducting an interview.

In the following paragraphs I will describe each step from two perspectives. First from the point of view of the team (as a working group after a common goal) and secondly, from the personal perspective (of each individual as a developer and of what it is possible for us to improve)

1. Do you use source control?

Team: Considering it was written in 2000, source control was a growing practice but hadn't really reached current levels. I remember back in 1998 when I just started working with systems, we controlled the concurrence of source files by changing the attribute of ''read only'' from the files and all the sources were saved in a server which had a weekly backup.

Nowadays, there is no reason not to have an adequate source control for the team. GitHub, VisualStudioOnline, Bitbucket, TFS, Mercurial, a local git and several more options can save us today from having to recover hours and hours of development because of some unexpected event.

Personal: We must be capable of creating our own version of the work, of recovering a previous version of some source and understanding the concepts of ''Branching'' and ''Merging''. After working for some time with VisualSourceSafe, I changed to ClearCase, then Mercurial and finally Git and TFS, so we must keep up with the latest trends.   

2. Can you make a build in one step?

Team: This means that when generating a new version of the application, it shouldn't involve a series of steps that will discourage us from wanting to do it. In other words, the effort of having a new application to test should be low, and therefore allow us to compile as many times as needed during the day without it being a problem.

Personal: We must assess whether we have the knowledge to do it. Meaning, if tomorrow whoever is doing the compilation is not available, are we able to cover for them? If not, then this is something we should work on.

3.Do you make daily builds?

Team: Of course each system is different, but most of the time we should be able to make daily builds, that is, taking the entire source control repository available at the time and generating a compilation in the system. This way, we make sure the system is consistent throughout time, and that the changes will adjust every day so that if someone uploads a change and hopes not to crash anything, we have enough time to fix it.

Personal: We must know the result of the daily builds and be able to identify who worked on the version that broke.

4.Do you have a bug database?

Team: Knowing that Spolsky worked at Fogbuzz (a renowned system that recorded issues) it is not strange that he included this point. In any case, following-up on the errors we have identified in the application is vital to have a plan to correct the action and check if the overall general plan is possible.

Personal: It is our duty to know where the bugs are loaded and which ones are assigned to us. When you can identify which errors are repeated, it is more feasible to be mindful of not making them again. On the other hand, it is a great tool to get to know ourselves and what we do (or not do) without being aware of it.

5.  Do you fix bugs before writing new code?

Team: Depending on the type of project, one might have time to correct bugs during the development, whereas other projects might require waiting until we have the green light to move forward. In any case, it is highly necessary to plan when we will deal with bugs.

Personal: We know that when the work day comes to an end, we are more likely to ''try things'' that are not all that neat. We also think things like ''oh, I'll fix that later when I have time''. But if we get into the habit of checking things when the day starts to detect what can be improved form the day before, the code will become ''better'' without having to wait for a particular moment to check and fix everything (which usually never happens). 

6.Do you have an up-to-date schedule?

Team: We must know at any given time what we've done, what we are doing and what we will do. Having a schedule, following it, and updating it provides visibility, helps us plan our vacation, discover if there are problem or if there will be in the future.

Personal: A developer's tasks normally include: being methodical when finishing a development and always testing it, committing it in the repository, updating the plan and letting the rest of the team know. Precisely, to let the team know we must always keep our tasks up-to-date, which reduces interruptions, and this will help us be aware of the current status of a task. Finally, this gives us the possibility of knowing in advance if we will need someone else's help.

To be continued…

Marcelo Mosquera

Technical Expert at Baufest

Technical Expert at Baufest
 

Contact Us

info@baufest.com