Home Essays Talks Resources Bio

{
    Adam Ard
}


The Adam Test: A Few More Steps to Better Code

In the year 2000, Joel Spolsky published 12 questions for assessing the quality of any engineering team. These questions were immensely useful and are still relevant today. Over time, I have accumulated a few extra questions of my own. I hope you find them equally helpful:

1. Do programmers REALLY have quiet working conditions?

Even though Joel already put this one on his list, I wanted to repeat it (I added the REALLY for emphasis) because the industry has totally disregarded it. The norm now is to use flashy but useless open office plans that are full of noise and interruptions. Because the software engineering world is turned so backwards on this issue, I added a few follow-up questions to make it crystal clear what “quiet working conditions” REALLY are:

2. Do you divide, organize and assign roles instead of tasks?

This question may seem like a triviality, but it is hugely important. To put it simply, if you assign tasks to developers you are likely a micro-manager. But, if you assign roles (areas of major responsibility), you are utilizing the Covey principle of stewardship delegation. For motivation, and employee engagement, this distinction will make all the difference in the world.

For more on this read:

3. Are you careful to never fix the scope and release date for your deliverables?

Don’t let people fool you by trying to alter this equation. Many will comment that if you add people or resources, you can get around it. They haven’t read Brook’s Law. Others will say that you can cheat on the quality to push things through. But, in the end, if you aren’t aiming for high quality your team’s morale will suffer and you will lose more productivity from disengagement than you’ll gain by cutting corners. As a result, it is just better to concentrate on scope and date. Here are some good examples in the industry:

An interesting corollary to this is that you really shouldn’t waste your time in estimation exercises either — estimation by definition is picking a date and a scope.

4. Do you utilize strong code ownership?

Microsoft ran a study of their own extensive code base (if anyone has a bunch of code to run studies on, it’s Microsoft), and found that when only one person makes the majority of the commits to a file, executable or directory, those code units have a lower incidence of bugs.

You can whoop and holler all you want about how the magic happens when everyone holds hands and codes in perfect harmony, but the truth is, people need to own what they work on. They need to have separate responsibilities. They need to be able to think deeply about what they are doing, be a custodian of the conceptual integrity of their design, and they need to be left alone to work on it.

This doesn’t mean that people shouldn’t bounce ideas off each other, seek advice of experts and peers, and be humble enough to except constructive criticism. It also doesn’t mean that they shouldn’t be transparent about what they are planning and producing. It just means that after all the advice comes in, and the ideas have been bounced around, one person needs executive authority over the decisions in a given domain.

For more on this read:

5. Are worker metrics kept private to individuals and never revealed to management?

It is best to avoid companies that rely too heavily on scientific management practices, also known as Taylorism. Programming in particular is not a profession that will benefit from being managed by trying to optimize a group of performance indicators. Anyone who has been managed in this way can attest to the dysfunction that it creates. Sadly, as soon as a worker metric is used to motivate programmer output, it loses its ability to be useful. Some people call this Goodhart’s Law.

When a measure becomes a target, it ceases to be a good measure

Tom DeMarco and Timothy Lister, the authors of Peopleware, recommend a novel way to maintain the usefulness of metrics--don’t let management see them:

Work measurement can be a useful tool for method improvement, motivation, and enhanced job satisfaction, but it is almost never used for these purposes. Measurement schemes tend to become threatening and burdensome.

In order to make the concept deliver on its potential , management has to be perceptive and secure enough to cut itself out of the loop. That means the data on individuals is not passed up to management, and everybody in the organization knows it. Data collected on the individual’s performance has to be used only to benefit that individual. The measurement scheme is an exercise in self-assessment, and only the sanitized averages are made available to the boss.²

6. Are you careful that managers have enough direct reports?

I don’t know what the ideal number of direct reports actually is, but I know it isn’t 2 or 3 or even 10. It is much bigger. “It is not uncommon for google managers to have 30 direct reports”³. Why does this matter? Because good managers don’t micromanage and they can’t if they have enough people to take care of. In a way, the number of direct reports assigned to a manager is an indicator of how an organization thinks about management in general.

7. Do engineers choose what they work on?

This one is rare but wonderful if you can find it. Valve’s employee manual famously tells new employees to go find a project they like because no one is going to pick it for them. Oh what a glorious world that would be. Hat tip to the enlightened companies that do this already — you are the future of management! If you find yourself at a place like this, hold it tight, and never let go.

8. Do engineers own and manage their own deployments and infrastructure?

This keeps your organization lean and scalable. Setting up a centralized infrastructure team is rarely a good idea because teams have such varied needs. The burden of keeping a shared infrastructure up all the time is not trivial. Additionally, dedicated devops teams tend to want to wrap essential deployment APIs in homemade access management tools, creating bottlenecks for engineers that are clamoring to use new aws services or kubernetes resources that haven’t been exposed yet. Trust your engineers to pick and learn the best tools for what they are trying to accomplish, and to safely and effectively utilize them. If you have up-time or security concerns, focus on training (books, conferences, courses) or consider an organizational model where you have a devops expert on each team that can teach and train the other developers. But don’t create a separate devops team.

9. Can engineers choose their own tools for task management and coordination?

Does your organization use something awful like Team Foundation Server or Jira (or any of a million other painful task trackers) to track and manage engineers? You are not alone. Man YEARS are wasted keeping these red tape generators running and up to date. It is simply not healthy to make engineers track and coordinate their work with a tool that they haven’t chosen themselves. If they want to use post-it notes or emacs org-mode, then let them. Questionably valuable reports that you get from big enterprise tools are not worth the loss in productivity and morale.

10. Do engineers have full administrative control of their machines? Can they choose their computer model and operating system?

This one is a no-brainer. Would you hire a mechanic but tell them they can’t use their own tool box? If you hire a Linux nerd that has spent a decade or more tuning their development configuration, it makes no sense to force them to use Windows or MacOS. It is equally counterproductive to make a Windows guru suffer through setting up a Unix based environment. Virtualization is almost always sufficient for providing ways to test and develop on alternative target environments. But peoples' host machines, their home base, should be what they are most comfortable with.

And when they get their machine, don’t lock it down so they can’t install what they need. If people are responsible enough to load software on their home computers, they are most certainly capable of managing the software on their work machine.

Summary

If you want a highly satisfying and productive culture, give these suggestions a try. And if you are interviewing, make sure that you know how your potential employers score on the Adam Test — let that help you make a decision of who to work for. You won’t regret it!

Sources

1,2. Peopleware by Tom DeMarco and Timothy Lister

3. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management