I feel a bit of a rant coming on. This is about software developer mindsets, but it's also about "processes", which can be a bit of a scary term to many developers.

I got quite lucky in my career, in two particular ways.

First, in my first job I struck up a pretty good relationship with our CTO. He and I had quite a few conversations about the why and wherefore of what we were doing, from a business rather than a development perspective. That has left me with an interest in the big picture.

Second, I got sucked pretty much from the get-go into ops. We called it system administration then.

For $reasons, I used to be one of the few developers who got root access to production machines in a bunch of companies.

This has helped me get a fairly good understanding of what operations require from developers. It's quite different from what developers require from each other.

In some ways, it's the exact opposite.

The way these two things fit together is through the nebulous concept of "processes", which most people seem to immediately associate with some ISO standard and certifications, which is followed by endless amount of documentation, which must lead to the conclusion that processes must stand in the way of developers doing what they should be doing, which is programming.

I used to be like that.

So what does operations require from developers?

Developers often think of that in terms of "make things easy for ops", such as giving them a single binary to run instead of having them wade through configuration files. And to a degree, that's a fair enough goal to have for devs.

But the truth is, that ops tend to have some coding ability, and there are a ton of configuration management tools out there and in active use.

Complex setups that can be scripted aren't all that complex.

In fact, what operations require *more* from software is adaptability. The way devs tend to run software is usually *not* the way ops need to run it. Simplicity can be a bit of an own goal.

Or, to put it differently, while ops are end-users, they're not to be confused with grandpa trying to figure out this new-fangled electronic mail thingimajig.

What ops require above anything else from devs is boring.

No, really, that's it. Software should be boring.

That is, it should be predictable.

Configuration file formats changing, interfaces changing, setup procedures changing, requirements changing - all of these things shouldn't happen.

Of course they will, and they will have to. That's where scripting helps ops out again. But that means that any change in what ops can reasonably expect must be documented and the documentation communicated in a manner that ops can deal with.

You cannot communicate this the day before a new release should go live.

Which brings me back to processes.

A process is nothing more than putting this communication in place.

The way this manifests is most typically through checklists. Follow steps a-z in your release from dev to ops.

But what these checklists *encapsulate* is the organisation's understanding of the needs of ops from devs (and vice versa for e.g. bug reporting procedures, etc.)

QA is usually in the middle of this process, adding the required check mark on one of the boxes on the list.

Every organisation has a process for this. Every single one of them. Even if it's "oh I just upload that JS file to the production server", that's a process.

It's a shitty one, but it is one.

What is often missing are the checklists. And some structured discussions around how to get to checklists. All of which is shorthand for communication.

The discussions tend to lead to more or less the same place: you either need a gate, or you need recovery.

A gate is a kind of barrier in the process that is somewhat cumbersome to pass, but if you have the right key, passing isn't all that hard.

QA is such a gate. If you cannot pass QA's requirements - which is usually in the form of regression tests and new feature tests - then you cannot go to production.

Recovery refers to the set of procedures you have for rolling back to the last known state in case of a production failure.

Recovery tends to be good in orgs with weak gates and vice versa.

I'm a bit traditionally minded here, and personally prefer my gates to be strong. The industry as a whole tends to prefer strong recovery. There is almost always a mixture of the two employed.

In the end, it barely matters. What matters is that the business goals are met reliably, and the delivery team is not unreasonably stressed out by their combined efforts.

What the whole thing requires regardless of the balance struck here is that developers take some ownership.

This isn't to say that developers "own" that everything goes smoothly. That would be an exaggeration.

But they cannot reasonably have the mindset that throwing code "over the wall" is their job. Their job is to provide to the next down the line - QA, ops, both - exactly what those parties require to do *their* respective jobs.

"Worked on my computer" is a symptom of this being broken, same as "no errors in the CI" or whatever form it takes.

I sometimes exaggerate this and say "your job is only done when the end user - aka grandpa - successfully uses it to solve their problems". This is more for illustration purposes than as a real assignment of responsibilities. Exaggeration is a it double-edged, people can take it too seriously. But often enough it carries a general point across fairly well.


I'm a savvy user, but know nothing about programming. Let me give you my take on this, OK?

Your job is only done when your software allows me to do more in less time than not having your software allows.

Most software does not pass this test. Indeed I think in my entire life of using ever-increasingly computerized systems, I can count on one hand where computers have improved things.

Yes. It is that stark.


As an example, at work we have a contact management system. Contact management is absolutely **KEY** to our business. If we screw this up, our business dies.

The contact management system, installed and configured by conslutants (sic) of the worst kind, is so unreliable that literally everybody who is client-facing prints off key clients into special notebook pages so that we can use those instead of this system.


While this system is the most egregious of the lot, even a lot of COTS software we use is utter crap. I have a rhythm of automatically hitting Ctrl+S while working every five minutes or so, no matter what software I'm using (except that crap management system which manages to screw even "save" up…) because out of nowhere the computer might suddenly decide that it's had enough and will throw a tantrum, losing any unsaved work.

@zdl @zdl I hear you.

I tend to think of this as more of a joint responsibility for the organizations that produce your software, while the developer's role is more limited. They have to do their part of the job to enable everyone else to, ultimately, fulfill this at the organizational level.

But as a shorthand, it absolutely is that stark.


I don't know. I think "not crashing" is a pretty basic requirement for all software, no? :D

@zdl @jens You can say the same for cars. Pretty basic requirement there.

Yet, cars still crash...

because they're on roads, and roads are unpredictable.

Put a car near a tree, tree gets hit by lightning, falls on car. Car has been involved in a crash.

Now, why didn't the designers have a fix for this? I paid good money for that car! Why can't car people DO THEIR JOBS?

Because *no one* can predict everything that will happen at all moments.

You can work very hard and try to predict everything... but as mentioned in parables...

build an idiot proof thing, they build a better idiot.

@Truck @jens

Cars crash when in unusual circumstances and/or when the driver is taking unusual actions.

Computers crash sitting there doing nothing.

There is absolutely no comparison. Any car that was as unreliable as the **best** of the software that I use every day would be, in Canada, returnable under the so-called "lemon laws".

@zdl @jens

I'm going to point to the tree falling on the car again.

I'm also going to ask if you leave your car without maintenance. If you do, then - well, good luck with those lemon laws.


@Truck @jens

By continually missing the point—quite deliberately, I'm positive—you are ensuring that software remains utter shit and that those who use your software continue to call it utter shit.

If you feel the need to have the last word, it's yours. I'm through dealing with the wilfully obtuse.

· · Web · 0 · 0 · 1
Sign in to participate in the conversation

This is a brand new server run by the main developers of the project as a spin-off of mastodon.social 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!