a blog about innovation and solutions
opinions

Professionalism in the development of software products. Or, what a CTO expects from the development teams

During interviews, I often get to talking about SOLID. The expectation is that the OOP programmers have heard about and are applying the SOLID principles in their day-to-day life. SOLID is a set of 5 fundamental principles which constitute the bases of a well-written code.

The experience shows that, unfortunately, the acronym aggregating the 5 principles introduced by Robert Cecil Martin – an emblematic name in the software field, known mostly as Uncle Bob – is more often than not omitted from the development path of many programmers. This aspect touches on a wider problem which has to do with the nature of the profession and, eventually, with professionalism in the field of development of software products.

solid

 

Paul Graham, founder of the famous Y Combinator accelerator and author of many essays regarding excellency in software development, wrote in an article titled “Great Hackers” that extraordinary programmers find passion in what they do and that more than anything (including money) they expect to be challenged, to feel that every day there is a new challenge that they have to deal with. “Ordinary programmers write code in order to be able to pay their bills. Extraordinary programmers see their activity as a pleasure and are happy to find out that there are people willing to pay for it,” said Paul Graham.

Not all programmers are extraordinary, but all programmers should be professional. All programmers should be able to go home, watch themselves in the mirror and say proudly “Today I did a good job.” The wild growth of the IT industry lately has left us little time to focus on aspects regarding promoting some fundamental values that concern professionalism in software development, and I would like to use this opportunity to discuss some of these values.

15 things a CTO expects from the development teams

Uncle Bob was talking in 2012, at the Software Craftmanship North America conference, about 15 things he would expect, as a CTO, from his development teams. I feel it is important for these points to be promoted, considering that them being adopted by the development teams could have a massive impact on delivering quality software products.

So here are the 15 expectations defined by Uncle Bob from the professional product teams:

#1 – We will not ship shit

Why do we have to mention this? Simply said because, in the past, software development teams have shipped poor quality code, and this has to come to an end. It comes down to everybody’s responsibility, to the essence of a professional attitude.
/

#2 – We will always be ready

What does this mean? It means that when we are asked to do deployment, we will be ready to do deployment. The peak of unprofessional attitude is represented by the famous quote “we have to wait for it to stabilize”. As if we were working with jelly. A professional team will write code which can go into production after every single iteration. A professional team will write code based on which they will win all the bets they made with the QA team. A professional team will always be ready.

#3 – Stable Productivity

Most of the time projects have high productivity in the beginning, but only a few months after the productivity falls to the point where someone decides to bring in another bunch of programmers, which, of course, only worsens the problem. The expectation is that a professional development team will have stable high productivity. Here is where a well-thought design comes into play, an architecture which will not make work harder after the first few months of development.

#4 – Inexpensive Adaptability

Openness to change is essential. We call it software for a reason, and that is because it’s soft. Why does a change in demands have to cost “a fortune” because the design has to be changed? A well-thought software product will be able to withstand cheap changes.

#5 – Continuous Improvement

The expectation is that a professional team will constantly focus on improvement: the improvement of the code, of the processes, the improvement of technology. The improvement must come from every individual, because, if not, it would come from “heaven” in a long black cape that has bureaucracy written on it, or it wouldn’t come at all, and then we would be surprised that it sucks when we go home and think how we learned nothing new.

#6 – Fearless Competence

When a programmer sees a code line and says “this code line is so ugly”, but they don’t change it, because, if they did, the line would become theirs, that programmer is a fearful incompetent. Professionalism means the opposite of this behaviour, namely – fearless competence. When a fearless competent worker sees badly written code, s/he changes it and makes sure nothing was damaged. The code won’t bite, but incompetence does.

#7 – Extreme Quality

Quality is poor in software. The development teams say it’s the sales teams’ fault, that the sales teams create pressure and that is the reason why the quality of the product is poor. Nonsense! Quality is poor because the code that was written is of poor quality, and when the code quality is poor, productivity goes down and there is a risk of new errors. Extreme quality talks about a basic principle of software professionals – quality gets higher, not poorer, under pressure, and that is because it is only under pressure that the true values of a professional can be seen. If someone is under pressure and they take shortcuts, it means that is what they believe in – shortcuts.

#8 – We will not dump on QA

It is not the job of the QA team to find bugs. In fact, QA should find nothing. After every iteration, QA should ask themselves “Why do I still have a job?”. and when QA finds something, the reaction of the development team should be “how on earth did that bug get there?”, not “ah, ok – let me fix it”. The role of QA is to make sure the product is valid and ready to be delivered, after the development team has previously checked it. A code that was checked by professionals will be ultimately validated by QA.

#9 – Automation

The automation of testing is vital. Manual testing should be an exception, not the rule. The cost of manual testing is enormous, but automation has the disadvantage of being seen as an unnecessary expense in the short run. A professional team will not accept not having automation implemented in their products.

#10 – Nothing Fragile

“We cannot touch that module because it’s fragile”. What does this mean, it’s fragile? A professional development team will always be in control when it comes to the code they create and manage. The fragility of a module is proof of lack of control and, consequently, of lack of professionalism.

#11 – We cover for each other

A product team is first of all a team, and a team helps its members and can replace them if the need should arise. On a ship, the crew has clearly defined tasks to do, but under demanding circumstances every member of the crew can take over from anybody else. Product teams should make sure that there is at least one other person who can replace every member, and it is their duty to do so. The situation when a member of the team goes on holiday (or, as it were, gets hit by a bus) and the whole project stagnates because of this is completely unprofessional.

#12 – Honest Estimates

When a programmer says “it will take me 50 hours to finish this”, that programmer is lying. There is no way one can be that precise in their estimates. Estimates have to be honest, and honest estimates come as an interval accompanied by a distribution of probabilities. Honest estimates will be correct and they will also be devoid of pressure, because, when someone asks “Can something be done for this to be finished quicker?”, the programmer who gave an honest estimate can answer “No.”

#13 – You have to say “NO”

Saying “No” is the most important duty of a professional, and when a company hires a professional, that company implicitly expects to be told “No”, as well. When does one have to say “No”? Obviously, not when one doesn’t feel like doing work. “No” has to be said every time when “Yes” would be a lie. Professionals never lie, so saying “No” is part of being a professional.

#14 – Continuous Aggressive Learning

One of the main attributions of a software developer is to learn. The software industry is developing at a very quick pace. New languages and new processes appear, which is the reason why a programmer who lags just a little bit behind might never recover. A career in programming is like surfing – if you want to float, you have to stay on the wave, and, for one to stay on the wave, continuous aggressive learning is essential.

#15 – Mentoring

The software industry has a big problem. Schools are not interested in creating professionals. Of course, in school one gets taught a programming language, algorithms, a few key principles and maybe the students will get the time to do one project (which they finish at 3 a.m., after going through a six pack of beers). But schools are generally preoccupied with turning people who know nothing into people who know something.

This is probably the most important role of software professionals – to turn IT graduates into professionals, which can be done only through mentoring, through educating and through the power of the personal example.

The chefs of the chefs

At Yonder we develop software products for other software product companies. One colleague was making the analogy of us being “chefs for the chefs”. If this analogy is correct, it means that the professional development of software products is even more important for Yonder than for our client companies. This is the reason why we are in a process of continuous improvement and why we focus more and more on the need for performance, continuous development and professionalism.

How does the organizational culture regarding professionalism change inside a software company, through the implementation of the 15 principles formulated by Uncle Bob? Everything starts from the individual. It is an individual decision whether a programmer wants to be a professional or not. Some of them will decide to be professionals, others will imitate those who already are, and those who remain fearful incompetents will swim to the shore without their surf board, which will have been caught in the aggressive wave of continuous change.

 

Leave a Reply