Kate Heddleston makes some great points in The Null Process:

When people say they don’t want process, what they’re really saying is they don’t want formalized process. There is really no such thing as “no process.” A process is simply the steps it takes to complete a task, so if a task is completed then by definition a process was used. Without formalized process everyone does things their own way, and there is no documentation for how problems are solved. This informal, undocumented process is the “null process,” and, if used incorrectly, the null process can have major implications for a company.

This reminds me of two things. The first is Rebekah Cox’s definition of Product Design:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

What this implies is that everything you do in product design has a consequence. So just “letting things happen” is also a decision. It’s just a pretty bad one. Maybe that should be called “null design.” I don’t know, I’m not good at naming things1.

The second is Michael Lopp’s The Process Myth. The whole thing is great, but this quote in particular has always stuck in my mind:

Engineers don’t hate process. They hate process that can’t defend itself.

Also this advice:

Healthy process is awesome if it not only documents what we care about, but is willing to defend itself. It is required to stand up to scrutiny and when a process fails to do so, it must change.

For more reading on what it takes to build good processes (because let’s be honest, what else are you going to do on a Friday night?), I recommend Adam Wuerl’s Avoiding Process Hell and Jeff Gothelf’s Applying Product Thinking to Process Improvement.

---

1. Just look at my URL. Seriously, what was I thinking. ↩

Shaun McCormick describes Why the way we look at technical debt is wrong:

Technical debt is ok, and often a solid product strategy. The importance is getting to market. When launching a new system or feature, focus your effort and time on areas of the product that need to be agile, and move quickly through areas that don’t. Later, if the product proves that it can drive revenue, you can revisit those areas and improve if they need to scale.

This is an excellent sentiment, and I agree 100% in theory. The problem is that in most organizations, “later” = “never.” Or as Jeff Gothelf puts it, the biggest lie in corporate america is Phase 2.

That’s why I really like Henrik Kniberg’s concept of a “technical debt ceiling.” Read his post Good and Bad Technical Debt (and how TDD helps) for the whole explanation, but here’s a diagram that explains his point:

Source: Henrik Kniberg

This forces teams to pay attention to technical debt, and make a conscious effort to reduce it when it becomes a problem.

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog1. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

---

1. It’s kind of hard for me to link to this. First, there’s no byline, and I’d love to quote the author by name. Also, wow, that stock image… ↩

Marty Cagan continues his excellent product autonomy series by discussing what happens when teams get large enough to split up their code bases. In Autonomy vs. Ownership he describes his preferred way of dealing with the situation where a team needs a change in a different codebase to get one of their features implemented:

The alternative model is informally known as the “open source” model although to be clear this is not about open sourcing your code, it’s just called that because this is how much of the open source community operates. In this model, if the drivers team needs a change to the riders team’s code, then they could either wait for the riders team to do it, or they can actually make the change themselves, and then request that the riders team review the change, and include it if they’re okay with it (known as a “pull request”). This means that you are telling the software management system that you’ve made a change to the software, but the owner of that software needs to review the changes before they are actually approved and incorporated.

Judy Wajcman’s Who’s to blame for the digital time deficit? starts off like many similar articles as she ponders the role smart phones play in making us feel time-starved. But then she takes an unexpected and well-reasoned turn:

If technology is going to contribute to a better world, people must think about the world in which they want to live. Put simply, it means thinking about social problems first and then thinking of technological solutions, rather than inventing technologies and trying to find problems they might solve.

We can’t do this while the people who design our technology and decide what is made are so unrepresentative of society. The most powerful companies in the world today—such as Microsoft, Apple and Google—are basically engineering companies and, whether in the US or Japan, they employ few women, minorities or people over 40. […] Such skewed organisational demographics inevitably influence the kind of technology produced.

And later on:

If we want technology to bring us a better future, we must contest the imperative of speed and democratise engineering. We must bring more imagination to the field of technological innovation. Most of all, we must ask bigger questions about what kind of society we want. Technology will follow, as it usually does.

Charles Fishman’s They Write the Right Stuff is an incredible profile of the engineers who write software for NASA’s space shuttle missions:

How do they write the right stuff?

The answer is, it’s the process. The group’s most important creation is not the perfect software they write — it’s the process they invented that writes the perfect software.

It’s the process that allows them to live normal lives, to set deadlines they actually meet, to stay on budget, to deliver software that does exactly what it promises. It’s the process that defines what these coders in the flat plains of southeast suburban Houston know that everyone else in the software world is still groping for. It’s the process that offers a template for any creative enterprise that’s looking for a method to produce consistent—and consistently improving—quality.

The article goes on to explore the four propositions that underly everything this team does. Also see if you can spot what’s different about their working hours…

Jessica McKellar gives some fantastic career, management, and leadership advice in This Is What Impactful Engineering Leadership Looks Like. The interview goes into detail on three main areas:

“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.” 

Even though the interview is focused primarily on engineering teams, it’s applicable to all types of leadership and management. Highly recommended.

Rune Madsen wrote a really interesting post on how our design methods need to change when we work in software (as opposed to print). He explains in the post On meta-design and algorithmic design systems:

So what is meta-design? In a traditional design practice, the designer works directly on a design product. Be it a logo, website, or a set of posters, the designer is the instrument to produce the final artifact. A meta-designer works to distill this instrumentation into a design system, often written in software, that can create the final artifact. Instead of drawing it manually, she is programming the system to draw it. These systems can then be used within different contexts to generate a range of design products without much effort.

I’ll add my vote for the need to spend much more effort on design systems (like Atomic Design) upfront, to standardize (and eventually speed up) later development.

Richard Seroter’s 10 Architecture Tips From “The Timeless Way of Building” is highly relevant to software development as well:

“Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building  (software application) is ever perfect.  We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.

Just as buildings need “repair”, software takes iteration to get right.

Sticking with the theme of remote work, Steven Sinofsky wrote a great post called Why Remote Engineering Is So Difficult!? There’s a lot of food for thought, but here’s the main issue:

The core challenge with remote work is not how it is defined right here and now. In fact that is often very easy. It usually only takes a single in person meeting to define how things should be split up. Then the collaboration tools can help to nurture the work and project. It is often the case that this work is very successful for the initial run of the project. The challenge is not the short term, but what happens next. […]

If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code. It is a constraint that creates unnecessary tradeoffs.

Projects often start off ok, but then start to unravel as every small miscommunication and missed messages add up to a much bigger problem. I find this stuff fascinating not just because I work at Jive (where we don’t use email at all), but because we’re seeing such an explosion of remote work everywhere as our tools keep getting better and better.

Steph Yiu’s post Still figuring it out: communicating remotely with lots of people is another good one to read, since she walks through all the tools they use to get their work done. Our setup at Jive is very similar, except that we use our own tool where they use P2 (their Wordpress intranet theme).