Back in 2005 I had an interview for a job in a software consulting company in the French-speaking part of Switzerland. The interview in itself was dreadful; the hiring manager was certainly more interested in the “gaps” in my résumé than anything else. But one thing drew my attention, and made the interview nevertheless memorable; this person boasted that their company was one of the few “certified CMMI level 2” in Switzerland, and that they were in the process of preparing for the “level 3” certification.
To be frank I had no idea what this person was talking about; so I looked online and discovered that:
Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. (…) It is required by many United States Department of Defense (DoD) and U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.
Methodologies
The important word in the quote above is “claims.” CMMI is just another quality framework, just like ISO 9000, Six Sigma, Total Quality Management, or even the Joel Test; the primary job of these frameworks is to provide a nice (and sometimes very expensive) badge for companies to feature in their website, getting C-level managers to tap each other on their shoulders and give themselves another huge bonus.
A quality framework does not, per se, provide any insurance against big balls of mud. It does not establish any expected level of quality. It provides no insurance against impossible deadlines, crazy customers, developers with family issues, computer failure, misleading vendor marketing, or anything else. Yet, companies all over the world subscribe to these and other frameworks, creating an industry of speakers, consultants and conferences worth billions, yet unable to answer The Real Question That Everybody Asks About Their Software Project™®©:
Will the project be finished in time, delivering the features the user needs, and within budget?
If these frameworks are of no use, what is then, the magical factor that separates the (few) companies releasing quality software in time (there are, believe me) compared to the rest? Why do most projects end up with a Death March instead?
About Quality
I tend to describe Quality with a simple phrase, almost a mantra; a phrase very easy to remember, borrowed from a book somewhere, which I will shamelessly transcribe here for you to invoke ad nauseam in your next meetings; répétez avec moi:
Quality is doing the right thing, and doing the thing right.
(As the astute reader has guessed by now, the quality frameworks discussed in the previous section only care about the second part of the statement, if anything.)
But what is the thing we have to do, and rightfully so? Well, in the case of software engineering, that “thing” is not software – and I am pretty sure I have just made a few eyebrows raise in perplexity. No, ladies and gentlemen: the “thing” in question is the following:
To take care of your team.
There you go. Here is my invoice. Welcome to the light. There is no other thing to know.
Quality is taking care of your team. A product with good quality is simply a side effect of a team being taken care of (sorry for the functional programmers among my readers.) Do you want quality in your software product? Take care of your team. (Hey, Graham, we should start a software consultancy and copyright this idea fast.)
The Ipsum Quality Process
And what is, exactly, taking care of a team? I am glad you asked. Taking care of a team can be defined as a set of 12 simple bullet points that you can start following right now in order to make better software:
1. Hire inclusively
Having members with disabilities is important for your team – if anything because, among other reasons, it can help make your product more accessible.
Having team members from other cultures is important for your team – if anything because, among other reasons, it can help make your software multicultural.
Having people with various ages is important for your team – if anything because, among other reasons, it opens up opportunities for coaching and mentoring.
Having people from all genders is important for your team – if anything because, among other reasons, it will make the world a wonderfully better place.
All of this is important for your team, and hence it is important for your product, for the industry, and for the world.
2. Pay your engineers decent and equal wages, including extra hours
The software engineering field is extremely profitable, and it is not unheard of for a consulting company to have margins well above 30 or 40 percent. Why is it then that only managers get bonuses at the end of the year? Why do not these companies pay extra time? Why is it that the salaries of software developers are going down?
One of the main reasons of this situation is the lack of unions in our field; the bargaining power of software engineers is scattered, atomized, which was exactly the objective of the managers of businesses in the first place. As a developer, you must ask for a clear, open salary policy, and make sure all engineers are being paid in equal terms in correlation to their experience, regardless of age, gender, nationality, skin color, or any other attribute.
Regarding extra time, if it must happen for any reason, pay it and then compensate it with extra days for rest (see point 9 below.)
3. Stop cramming people in open spaces
Get private offices for your team, with at most two or three people in them. Forbid the use of smartphones and Skype and Hangouts in those rooms; they are there to be used for those three or four hours of deep concentration that make projects move forward fast (see point 9 below.) Set up many team rooms with whiteboards so people can discuss and talk. Isolate all of those rooms acustically from one another.
You need to coordinate, yes; but not as often as you need to get things done. Do not say that private offices are more expensive, because they are not – at least not in the long run. Have a broader mindset and stop telling lies.
4. Do not offshore projects
Offshoring software projects, that is, outsourcing them overseas, is the 21st century equivalent of economic imperialism, keeping countries in Latin America, Asia or Africa earning peanuts while agencies fill their pockets, and blocking the development of those countries. Emerging economies should be building their own products, and developed economies should pay for those products. This is the way to development; not imperialism.
All countries need software engineers to stay where they are, if anything because their salaries feed a greater economy. And also, the trouble and the mess of managing a project overseas is actually going to eat all the benefits of having a team located next to you, so do not even think about offshoring.
5. Train teams in old and new technologies
Give everybody in the team a certain budget to spend in conferences, online courses, and reading material. Make a library of physical books and stack it with some timeless classics. Give your team clear learning objectives, such as getting certified, preparing a 20-page document to share with the team, or talking at some event, and set up bonus structures tied to those requirements.
Make them teach each other all of those new things, continuously; either in pair programming sessions, either during code reviews, or in small 20 minute talks in the conference room in front of the whole team (which is a good exercise for people new to public speaking.) Review that your team has learnt and look up to the horizon. Rinse and repeat.
6. Drop the foosball, ping pong, pool table, karaoke, game console, …
Seriously. It only shows that all you know about developers is what you learnt watching episodes of “The IT Crowd.” Those things are not only annoying, they are vexing and demeaning.
Build a library instead. With books, you know, the dead tree kind, and some coaches; a water boiler and some tea; quiet music, because relaxation is key. Offer a place for relaxation and your team will love you. Peace and thoughtfulness will make your team create better software. Certainly not foosball tables.
7. Watch for mental health issues in your team
Mobbing, burnout, harassment, depression, fatigue; all of these things are happening right now in your team. Oh yes, they are. Are you even paying attention?
8. Watch for body health issues in your team
Does your team have standing desks? Do they have good lightning? Do they have air conditioning in summer and heating in winter? Do they have to use noise-cancelling headphones every day? Do they have good monitors to prevent strain in their eyes? Are they sitting in confortable chairs? Do they take enough pauses? Do they use ergonomic keyboards? Are they doing extra hours? Are they eating in front of their computers? What are they exactly eating?
9. Plan for 6 hours of actual work per day
Each workday should be divided as such:
- 4 hours a day of actual work (coding, writing documentation.)
- 2 hours a day of mingling, drinking coffee, lunch, meetings and coordination.
- And 2 hours a day for learning something new.
More than 6 hours of actual software development work per day is a recipe for disaster, burnout, and turnover (been there, done that.) If your work laws mandate 40 hours a week of work (which is the case in Switzerland,) make sure that those extra 2 hours per day are spent learning something new instead of writing more code (see point 5 above.) Send your team members home at the end of the working day. Turn off the electricity in the office if needed, so that they actually leave. Compensate for extra time (see point 2 above.)
10. Embrace remote work
Remote Work Works™®©. And beautifully so. Our field is perfectly suited for working from home. Embrace it and drop the requirement for command and control. You are going to make economies, and your employees are going to love you more for this.
11. Do not be a project management methodology fundamentalist
You do not need to have a scrum standup meeting every morning. You do not need to have that retrospective every two weeks. You do not need to follow the PMI workbook to the letter and punish those who challenge it. Doing so is nothing else but cargo cult. Remember this:
Waterfall has put a man on the moon. What has your methodology done so far for your team?
12. Change your approach to job interviews
Stop asking about round pot hole covers. Stop those live coding challenges to reverse a linked list. Drop the academic requirements. Instead, hire for character first, and then for skills.
Of course you need to be sure if the candidate can do the job, so here is a simple technique: hire them to work in your team for a day. Just a day. Pay them a full, fair freelance rate (see point 2 above) and watch them evolve in your team. At the end of the day, ask yourself and your team these questions:
- Were they good at reading code?
- Were they nice people?
- Did they suggest improvements to the code?
- Did they ask good questions?
- Did they behave ethically?
- Did they say “I do not know” often enough?
- Were they humble?
- Did they show empathy and kindness towards other team members?
- Did they looked happy being there?
- Did they ask about code coverage or the CI setup?
- Did they offer to help, even if the time was short?
- Did your team come back to you with big smiles asking you when they were going to see them again?
If most answers were “yes,” just hire the person.
Disclaimer
If you are a project manager or software CEO reading this article, you must be asking yourself the following question: does the Ipsum Quality Process guarantee the outcome of my project?
No, of course not. You can still have incompetent people making bad decisions, even if they are healthy, well paid, and enjoying excellent work conditions. But at least you will have reduced your employee turnover; you will spend less money in hiring costs; employees will have less sick days; they will be proud of working in those teams, and will attract their friends; they will end up doing everything they can for the company, including, why yes, writing high quality code yielding high quality products.
And I am not the only one who thinks like this.
Take care of your employees and they’ll take care of your business.
— Richard Branson, Founder of Virgin Group.
In short: only after your company fully implements the 12 steps above, we can sit down and talk about TDD, Agile, CI and whatnot.
Conclusion
To finish the anecdote that started this article, I heard the company (which shall remain nameless) went almost bankrupt, after taking in a project much bigger than they could chew, having it developed by an offshore team working in an open space. Most of their technical crew left the company less than half a year later. I read that they struggled to survive, and they ended up sacking most of their management and enduring a deep restructuration.
As for the CMMI level 3 certification, a quick look at their current website tells me they never got it, or they just do not care about it anymore.
“Move fast, break things and piss off the ones taking over” ™️©️®️
Cover photo by Philip Swinburn on Unsplash.
