The changing nature of breakage

Software is changing. So are its problems.

Software today is developed in a more regimented and orderly manner than twenty years ago. A few good practices have taken hold:

• Version control
• Code review
• A sort of of agile development
• Coding standards
• Wide use of libraries, toolkits and frameworks

These are good things. Even if the agile development is often a parody of what it could be, it's still a net positive factor, in my opinion.

These good things have bad effects, too. Perhaps most notably, developers don't know what their third-party code does, and that affects what they know about their own software, and what the users can know and do.

Code gets used because of some known function, without anyone learning the full scope of functionality. Take Ruby on Rails and the action-mailer package, for example. If you want to send HTML, you probably want an add-on package that modifies your site's CSS for common mail reader compatibility, Premailer is the most common one.

There will be an issue in the issue tracker to add Premailer and fix CSS compatibiliy. Some team member will take the issue, add the necessary five lines of code, test that it looks right in gmail and outlook, write a test, and that was it. The premailer web site doesn't say whether premailer takes care of printouts (@media print {...} in CSS), and most likely noone on the team will ever know whether that works or not.

That lack of knowledge results in poor documentation and bugs around the edges. The team doesn't know everything its software actually does, and as a result, the team writes bland, incomplete documentation. It's growing harder and harder to read about something and think ok, i know what this does, and one reason is that the authors of the documentation don't know what the software does.

Today's software has lots of unintended and untested functions. If the software uses Ruby on Rails, it may well use a gem that reads and converts two hundred image formats. Those formats aren't supported, they just happen to work. They're supported and tested in the third-party gem, not in the software users use. The users have to experiment to see what the software does. Do features such as colour spaces or translucency work?

Software suffered from a lack of support in the old days. Most of the 200 image formats weren't handled at all, CSS in email wasn't generated at all. Now it suffers from a lack of insight into what the code actually does. The maintainers don't know whether colour spaces are handled in the way users may expect, the documentation doesn't say, and the users have to experiment as soon as they use anything other than JPEG.

A second ill effect is that the lack if insight dampens the vision into what the software ought to be, making today's software incoherent. In the old days it was more likely to be incomplete than incoherent.

Wietse Venema and Postfix are a great example of how this can work. I've written on this blog that if you combine any two Postfix settings, the combination works as intended because Wietse has thought about that combination. Wietse knows Postfix deeply. If someone comes along with a proposal to implement a new feature, Wietse will know how that actually interacts with every existing feature and also how it ought to interact.

That depth of vision is difficult to achieve if your software handles image files, but you don't even know whether or how your code handles colour spaces in some formats. Or if you do know it, you don't know whether that's an accidental or intentional feature of the third-party library you use.

Some people do have vision. I've come across several CEOs and startup founders who used their product harshly, knew what it did and knew its soul, too. Not so many developers any more. A decade or two ago, some developers knew their code inside-out too, that's impossible now.

A small tool I worked on in 2016 had 1514 third-party dependencies, and that was one of 50+ systems being maintained by a team of 10-15. Just knowing all the 1514 by name is inhuman.

Most developers don't have any chance to attain complete insight, so things like Scrum meetings typically happen without anyone really insightful in the room.