Aug 25, 2016

The Reasonable Expectations of Your CTO

(assuming your CTO is reasonable)

As part of the Software Craftsmanship North America 2012 conference, Uncle Bob gave a relatively short talk (~30 minutes) entitled “The Reasonable Expectations of Your CTO”.

I agree with the points that he makes, most of which can be summed up by saying “Your CTO expects you to be a software professional”. You can also read about some of these points as well as some additional ones in his book, The Clean Coder.

In spite of my agreement with the spirit of what Uncle Bob says, there are some caveats and some potential downsides to behaving “as a professional” that aren’t explored in the talk but are worth mentioning.

Ultimately though, I believe meeting the reasonable expectations of your reasonable CTO to be in the best interest of your company and your career as a professional software developer.

What is a Software Professional?

According to Uncle Bob, your CTO will reasonably expect the following:

Don’t ship shit.

The quality of the code you put out is a direct reflection of your professionalism. You should not deploy code you would be embarrassed to have attributed to you — be willing to put your name on it.

Always be ready.

If the business wants to deploy, you can deploy. No, it may not be literally right this second that you’re able to deploy code, but if your boss says he wants to deploy you should be able to do it within a week, preferably sooner.

Stable productivity.

Don’t start off making “huge progress” only to have it drop off after a month as you become crippled by technical debt. Progress at a manageable and consistent rate will (paradoxically) lead to speed in the future.

Inexpensive Adaptability.

Change should not cost a lot. Making changes to your code should be reasonably easy and not require a lot of time or effort.

Continuous Improvement

The “Boy Scout” rule. If you work on a piece of code and you notice something that could be improved, fix it. Leave the code cleaner than you found it.

Fearless Competence.

You must not be afraid of what you have created. You need to be able to change things without fear of breaking the system.

Hint: A robust test suite is a great way to gain the confidence to make changes without fear.

Extreme Quality.

The only way to go fast is to keep quality as high as possible.

(This point is related to “don’t ship shit” and “continuous improvement”.)

Don’t dump on QA.

It is not QA’s job to find bugs…they should find nothing. QA is still necessary because inevitably they will find things that were missed, but the expectation should be no bugs make it to QA.

Automation.

No manual tests. It’s a waste of time, especially as the scope of the tests grows larger, and a long feedback loop means you won’t run the tests often enough. Without tests, how can you be fearless?

Nothing Fragile.

No sections of the code are more susceptible to breakage than any others. Consistent quality is called for.

Cover for each other.

You are a team. Individuals don’t own their code, the team does. The loss of any one person will not cripple the team, with an added bonus of being able to take vacations without having your team hate you for stopping all progress.

Honest Estimates.

A single date is a lie. How can you guarantee something will be done on a specific day? Estimates should be provided as a range and/or with a level of confidence, and the estimate is honest and firm. The estimate is the estimate, and does not change when someone puts pressure on you to get it done sooner.

Say “no” (when no is the right answer).

“The most important thing you will do as a professional. Don’t ever say yes when you know the answer is no.”

Continuous Aggressive Learning.

The job of a software developer is to learn. This industry moves very quickly — it is unprofessional to stop learning. It may not catch up to you in a month or two but over time, your skills will become outdated.

Mentoring.

More experienced developers have an obligation to teach newer developers how things work. Help them develop good habits and discourage the bad ones. Universities aren’t (generally) concerned with graduating software professionals, so it is up to those who have been there for a while to bring newcomers into the fold.

The Potential Downside of Being a Software Professional

I am not saying that being a software professional is not something to strive for, however I want to point out one particular aspect that can have negative repercussions if your boss isn’t a reasonable CTO, or not aware of/in agreement with these aspects of software professionalism.

Working at a sustainable pace can get you into trouble if you work for an organization that values long hours and “sweat equity”.

The appearance that you are “working hard” (i.e. spending long hours at the office, always saying “yes” to any request for more, etc.) can be valued more highly than actually producing quality work that delivers business value.

Kent Beck talks about this a little bit in his writings on Extreme Programming where he mentions a brief anecdote involving two teams, one practicing XP and one not. The XP team delivers value on a regular basis and works normal 8 hour days. The non-XP team over-promises and under-delivers, but works long 10–12 hours days toward the end of the quarter and continually says they’ll get everything done. After everything is said and done, the XP team is fired because they appeared to be less dedicated and enthusiastic than the non-XP team, even though they did better work that matched their estimates.

I’ve had similar experiences in the past, although thankfully I wasn’t fired. “Being a team player” meant being willing to stay late to meet deadlines promised by someone else, not the people doing the actual work.

In this scenario, saying no equaled not being a good employee even if professionalism demands that I say so.

As an independent contractor, consultant, or highly-placed individual within an engineering organization, it’s easy (or easier) to espouse these ideas about what being a software professional entails without worrying about negative repercussions.

But what does professional mean, beyond the context of software? Like most words it has many meanings, but a pertinent one here from the Oxford English Dictionary is “a person who engages in a specified activity […] as a paid occupation.”

If acting as a software professional as outlined by Uncle Bob means losing my job as a software professional who gets paid, was it worth it?

I don’t think there’s a simple answer to that question. Certainly not one that applies for everyone in all situations.

So…What Do You Do?

I do believe that striving to meet Uncle Bob’s “Reasonable Expectations of Your CTO” will lead to the creation of better software and more business value, provided that the rest of the organization’s practices don’t undermine those goals.

If you’re working for the kind of company that places as much or more importance on the appearance of productivity as on actual productivity, you likely already know. If that bothers you (and if you’re reading this, it probably does), look for an opportunity where software professionalism is the norm (e.g. 8th Light).

On the other hand if your CTO is expecting you to behave as described in the talk, it seems pretty reasonable to assume you’re safe to behave as a software professional, so you’d better venture to meet those expectations.