Christmas Break

In the 15 years I’ve been working professionally, I’ve never been able to take all of Christmas break off (December 23-Jan 4, 2020).

I’m going to do that this year. I’ll be back to publishing my newsletter content to this blog on January 6, 2020.

See you in 2020, and I’m going to take this time to brush up on the lyrics for Auld Lang Syne.

“We’re having a hard time filling this position”

Mythical-Man month issues aside (adding people to a late software project makes it later), there are times when you just don’t have enough people to get the job done, so you’re trying to hire more developers, and it’s just not working.

I could write for days on this subject, both as a former hiring manager and as a developer with over a decade of experience evaluating companies.

Dan Luu, someone who is known for treatises on tech, wrote a piece that is especially relevant to this problem. Take some time, and read it. It largely mirrors my own experiences. Here’s what I would add to it for this audience:

1. If you want young developers without a lot of experience, focus on the glitzy: Free food, foosball tables, happy hours.
2. If you want experienced developers who are good at what they do, focus on the mechanics: developers pick their own computers and work equipment (any price under 10K), developers have quiet working conditions, developers get paid training and conferences (no hoops). This is an especially inexpensive way to lower turnover as well.
3. If you want bottom-line focused developers, focus on the how developers interact with the business: Do they sit in client meetings or have discovery sessions with clients? Or is that walled off from the development team? Do they have KPIs/OKRs that are about the business’s work? (For instance, Initech’s software team is judged by the retention rate of their SaaS product) Or are their KPIs or OKRs focused on developer issues? (Initrode’s software development team is judged by how many bugs are found, or how many features are shipped). Business focused developers will help you improve your retention rate.

This post originally appeared in my daily email newsletter. If you liked it, subscribe below.

Developer Affinities

We’ll say (jokingly) that developers are interchangeable, that if you lose a developer today you’ll be able to replace them with another with little or no change.

For something like construction, that follows a well-defined standard (every stick-built house will follow the same builder’s code), software is a bit more… loose in its standards, which allows for more variability in what a developer understands and is good at.

This leads to developer affinities — based on a developer’s career and their interests, they can wildly diverge from another developer of the same programming stack.

I know a guy, he’s a systems guy. He believes strongly in systems thinking and the Theory of Constraints. I wouldn’t ask him to design and implement a user facing feature, but I would put him in charge of any messaging or queuing in our system, and I’d also ask him to champion Continuous Integration/Delivery because he has an affinity towards that.

Every workplace has one of these, but I also knew someone who was spectacular at solving hard problems in the system. They weren’t ever going to be on the critical path for a release, but they’d get every hard production problem we could give them.

Neither of these developers are interchangable. If they were to leave finding a ‘hard problems’ person or a ‘systems thinking’ person is tough — and finding developers is tough enough for businesses. Nor could one swap for the other without things moving more slowly.

Until software development becomes rote, that will continue to be the case. It’s also why judging programmers against their peers can be fraught — no two programmers took exactly the same path and exhibit the same level of knowledge or affinity.

As a manager leading a team towards delivering value, finding out the affinities developers have is a good first step to maximizing everyone’s productivity and happiness.


– Think about the developers you work with. Where would they excel? would it be in developing CI/CD pipelines? optimizing the system? Writing back-end features? Focusing on user-facing design and those features? Do they have a knack for fixing bugs in a certain area of the system?
– Are they currently working in those areas? If not, why not?

Make it work like excel does

“Make it work like excel”.

I’ve heard this quite a bit from non-technical managers and (and even some technical ones). You can point to many features of excel that businesses use day after day to do large tasks. Excel powers businesses because you don’t have to be technical to master it, and it has 20+ years of documentation and “How do I?” covered.

From the software perspective, make it work like excel, is akin to asking your everyday development team to learn how to scale Mt. Everest — that’s the scale of the difference in saying it vs doing it.

I use excel as an example because you’re probably familiar with it; but the same example could be used for any commercially produced movie, TV Show, or piece of software.

The part hidden to us is that millions of dollars and years went into making the first version of excel — and they’ve had over 20 years to improve excel.

In instances where business people wanted me to ‘make it work like excel’, I’ve had more success stepping back and figuring out the business behind the spreadsheet.

Why is excel being used? Is it for data entry? Manipulation? Complex formulas? replacing rote text? Why is it there? Figuring that out then shifts the conversation from replacing a spreadsheet based workflow with a crappier spreadsheet-looking workflow to implementing a workflow that captures the essence behind why the spreadsheet was necessary in the first place — and that doesn’t take millions of dollars and 20 years.

I’m interested to hear from you on this: What do you use excel for in your business? What manual processes does it replace? Are you happy with it?

Sometimes the Inmates are running the Asylum

Do you ever get scared when developers come back from conferences? I do.

How many times have you’ve had a developer come back from a conference and say, “We should use framework X to build this?”

Recent examples would be, “We should make this into microservices” or “We should use Kubernetes”, or “We should write this new front-end in React.”

There’s a lot to unpack behind this, and I’ve been a part of numerous projects where this was necessary, and even more projects where this torpedoed any chance we had to meeting the expected business outcomes.

Corey Quinn, author of Last Week In AWS, speaks of this phenomena in his talk “Come Scale Away with Me: Solving for problems you don’t have” and its often negative effect on development teams and businesses.

Adopting new frameworks can be critical to the longevity of a business’s software, but those times are few, and the inflection points are often telegraphed (Microsoft has indicated all new development should target .NET 5 (rebrand of .NET Core), so if your business is running on ASP.NET 4.x, you’ll have several years of support ahead of you, but you should start considering moving off of ASP.NET to ASP.NET Core).

Framework changes are akin to tearing down and rebuilding a building. It may be necessary, but is a large capital expenditure and should taken with the same seriousness that building a new office building would be.

Four Levels of Delivering Software (For Enterprise Software Teams)

The ability to deliver software (physically turn ideas into working software that a customer can use) has different levels, and before trying to improve your team, it helps to know where you are. These levels are focused on Enterprise Software Teams (EST). Product Teams have a similar track with a different focus (they’re focused on revenue generation as an indicator of success). These levels are ranked from emergent to established:

1: Can turn a written specification into working software reliably
2: Can turn not-well-specified ideas into working software reliably
3: Can work with customer to elicit ideas to turn into working software reliably
4: Can challenge established norms and focus on delivering value over writing software according to customer’s stated needs

Agile, and Scrum specifically, work at levels 3 and 4. Most ESTs are at 1 or 2, and they believe that adopting agile (or Scrum) will get them to level 3 and 4.

If you look closely, there’s a precursor step before being able to adopt any agile methodology (like Scrum): The software team must be able to focus on the needs of the customer and be able to make the decisions necessary to improve the customer’s experience. Not a VP of Delivery, not a project manager, but the team itself.

Five ways to Go faster as a Software Team (That have nothing to do with Skill)

There are lots of ways to deliver software faster that have nothing to do with the skill of your software team. Here are five:

1. Tighten and clarify the vision
2. Choose well trodden, simple technologies (No one went broke choosing IBM*)
3. Remove the number of people involved in making a decision
4. Build the software to be disposable (no future proofing allowed)
5. Tighten execution focus to one thing at a time (no context switching)

*Switch this to your favorite well-trodden stack if you’re a programmer: Ruby on Rails, .NET, J2EE, Django. This is also known as the “You don’t need Cassandra” rule.

Literal Problems

Them: “We do scrum, we have 2 hour planning and a standup once a week for two hours.”

Developer: 🤔

And in that moment, the developer decided the company was clueless about software development processes.

Why? Because the Project Manager used words that did no mean what they thought they meant. Developers are finicky literal creatures. Their worldviews can tend towards black and white because to a computer there isn’t such a thing as ‘figuratively true’. A state is either true or it’s false, there is no in-between (this will not age well if Quantum Computing becomes mainstream).

Scrum has four ceremonies held at very specific intervals; and even the End Note in the Scrum guide says,

“Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

This is a rigidness a developer loves and a business person hates. For things a developer ‘knows’ about, they judge others competencies on using words as their meaning states. It’s an interesting profession, to be sure, and developers are so much fun at parties. The concept of “Nerd Sniping” is predicated entirely on developers exposing some incongruity in the world and sucking others in to the problem to think about.

But, if you want for your developers to respect and listen to you, you may have to give a little bit on some of these points.

There are two ways out if you care what your developers think of you:

  1. Don’t call what you’re doing Scrum if you’re not following the guide to a T;
  2. Risk alienating your developers and calling your process “scrum”

One Grade’s worth of Progress

We spend a fair amount of time in Software Development focusing on the big players. We focus on Netflix’s chaos engineering, the “Spotify Model” for software development, Microsoft’s (now defunct, sadly) private office layout for software developers, or Stack Overflow’s architectural approach to operating at their scale (Stack Overflow is a top 50 website in the world, and likely the #1 developer destination in the world).

We focus on them and we grade ourselves against them. Microservices migration failing? I guess we’re not as good as Netflix. Why has scrum failed for us when it worked for <big name here?> Why do we have so many bugs? Why can’t we do what Microsoft did and launch a “Zero Bugs” campaign?

One of the (many) lessons I’ve gleaned from following my wife’s career in education is the idea that each child learns at a different pace. We pay lip service to it as non-educators, but differentiated education really makes it a central thesis: Every child is different, why would every child learn at the same pace or in the same fashion?

Every software team is a single being, and that being knows, learns, and operates at a different pace and level than any other software team out there. Our methodologies and “best practices” are tailored after what we see the biggest and ‘best’ doing, but much like teaching a child to read or learn multiplication, what works for one won’t work for another.

To combat this feeling of ‘being left behind’, if all children aren’t evaluated to the same ‘standard’ (I’m using ‘standard’ here to refer to standardized tests), educators that use differentiated learning will evaluate each child against their own progress. Has this child made one grade’s worth of progress from where they were when they came into the classroom?

Has your software team has made progress against itself? Has it improved how it delivers value to your organization over the past year?

Is Pair Programming + TDD worth it?

I’ve seen three types of companies when it comes to pair programming:

1. We pair program on EVERYTHING.
2. No, we don’t pair program.
3. We pair when we need to.

Of course, it also helps to define what I mean by pair programming, because there are multiple definitions.

For teams that practice the classic definition of Pair Programming from the agile practice Extreme Programming (XP):

Pair Programming is a method of developing software where one programmer sits and the keyboard and “drives”; starting by creating a unit test, and then the other programmer takes over and writes the failing/passing code for the test. In this definition, the act of switching for every unit test is key.

In teams that do not practice TDD, Pair programming is two sitting in front of a computer with one keyboard and mouse for 30 minutes – 6 hours trying to solve a problem.

Pair programming paired with TDD is a great practice when you have people who are trained in TDD that can guide new programmers. Being able to teach TDD is key — there are lots of wrong ways to do it, and they end in frustration with the practice of TDD in general.

Pair Programming to solve a problem without TDD is how most programmers interact, and opinions range from ‘great!’, to ‘meh’, to ‘omg do we ever have to do this again?’

Recently I spent about a week on a problem that with a pair took me about 6 hours to fix and if the entire component had been created through TDD would have never occurred. It’s also taken me many years of practicing TDD and pairing to know that it wouldn’t have occurred had our team used a TDD+Pairing process.

So why didn’t I TDD that component? In a phrase, because the culture doesn’t support it. There’s no mechanism to get buy-in for something that is arguably akin to wearing a safety harness on a job site. (If wearing said harness caused everyone on the site to have to learn how to work in safety harnesses)

If you’re trying to deliver software for a project where the code isn’t going to last several years, maybe TDD and pairing isn’t worth it. If the domain isn’t complex and deep, maybe pairing isn’t worth it. But if the code is going to last at least 3 years, it may just be, provided you’re willing to train your programmers on TDD and pairing together.