In the last days before my vacation I had a great pleasure of attending to Mark Seemann’s workshop “From design patterns to category theory”, organized by Pau López – founder of NET community in Barcelona and DevOps Tools course Professor in Apium Academy. Mark’s workshop inspired me to reflect on some topics I had been thinking for quite a while now.

Finally, the time has come for me to review my notes and share with you what I have learned, what we have been talking about and some of my personal conclusions about the state of programming. Please do not expect a coding exercise today; even though we did quite a few exercises with Seemann, what I wish to share with you are general concepts like work organisation, good and bad practices and some food for thoughts. 

We started the workshop with some general ideas about our day to day work. We had to define a problem so that we could try to answer it clearly. We tried to look for a common base that exists in all the work we do. The struggles we encounter independently of the programming language we code in, methodology we use, or domains we model up in our projects. Let’s forget for a moment about compilation errors, bugs, features and get into important stuff.

Is just a matter of perspective

Sometimes it’s worth stepping out of the IDE for a while to see the bigger picture, to think about what the programming really is. Is it science, is it engineering? – Mark was confronting us. Is it both or neither of them? We don’t use scientific methods in the industry, rarely we publish articles based on experiment results in peer-reviewed magazines. Rather we meet up to listen about someone’s case study. Despite that there are countless theses written every year in universities around the world, pushing forward the knowledge boundaries and discovering new territories. The industry is rather focused on fast and reliable solutions for the problems of today, or maybe tomorrow if you get lucky. Or more often problems of yesterday, if we take into account the ever shorter and shorter deadlines for the development projects.

It’s no science, for sure, but programming is quite far from normal good old-school engineering too. By saying “normal” I mean, more SpaceX or Tesla than PayPal. You know, “the real” industry: mechanics, construction, architecture, robotics, bioengineering, chemistry… Maybe the architecture is the closest to our profession among the rest, at least in some twisted sense, right? We do borrow some jargon words from them too, and it’s easy to draw analogies to architecture, when explaining the code to non-developers. Needless to say, there’s the architecture of software, and there’s a lot of software in modern architecture.

A “tedious” process

Programming is quite often a manual repetitive labor. Time after time we have to apply the most well-known design pattern and there’s nothing wrong about it. Of course not “Factory”, I mean the “copy-paste”! 🙂 Maybe there’s no thrill or adventure when the requirements define a quite exact endpoint/form/view/component as the last time, but with a different model behind. As I said, there’s no shame in getting into the zone of relaxing, smooth and organized programming craftsmanship. But hey, that’s not yet all of the story right? Because sometimes we also do the “other” thing, the very opposite of “manual labor”, like reasoning, discovering, knowledge crunching. That thing which happens after you step out of your comfort zone, when you do something new. And doesn’t this job shine and glitter in those moments?

The discovery

I think there always was and there will always be something that’s new for me in coding. I’m pretty sure there will always be more libraries, frameworks and tools I’ve never even heard about, then those I’m somehow comfortable with. And the community releases, invents and reinvents more and more every minute so the ratio of known-to-unknown can only go worse! My former team leader once shared this with me: “When you get yourself hired for the job you already know how to do, you probably sell yourself short”. Don’t forget that the unknown is a natural part of your work. It’s all we do, forge the unknown and undefined into great workflows. If all of it had been so simple, we would have made ourselves unemployed a long, long time ago by automating all that… stuff! What I do see that has changed since I started to code is: programmers used to be hired into the “research and development” department, now we hire so many developers, we name departments just for them.

We want numbers

We often speak about cyclomatic complexity or code coverage. (No, actually nobody speaks about cyclomatic complexity :D). But we do a lot of metrics, and they hardly translate to real programmer life values. Many have seen a high test covered percentage, and still unreliable and fragile design causing some poor lad or gal to be woken up by the pager duty in the middle of the night. Or an extremely elegant block of code, yet inefficient or just impossible to extend without rewriting. It’s quite easy to come up with static metrics. Who hasn’t heard about story points, sprint velocities, number of bugs, turndown chart? What’s shared by most of those measurements is that they are post-factum computations. Mark stated it as “a weather forecast which predicts yesterday’s rain” – hard to argue.

What do we focus on when we try to measure something in our day to day work? And how many things can be measured in programming? I often hear, you should measure literally everything in your production environment. Not a bad strategy to be honest… Yet when it comes to people it’s not as easy as just saying “we want measurements”. There’s a hell of a lot of things that are poorly quantifiable yet really important. Enough to say everyone would love to measure performance or quality or at least satisfaction (user’s/client’s/team’s). Reality however escapes our best efforts to put a ruler over it and compare human behaviour with known patterns.

Speed versus Velocity

What about those productivity and efficiency values everyone seems to like so much? In Scrum we often measure some points, divide and multiply taking into account focus factors and amount of bank holidays in the next X weeks ahead. We get something, we use to call that “team velocity”. My personal belief is that the breakthroughs happen very independently of those “points” and “velocities”. Actually, what we often refer to as “velocity”, is actually wrong, velocity is the derivative of displacement in respect to time, which would mean which fraction of a user story point is being burned right exactly now. When you see a 80 kmph on the clock of your car it means you go that fast at this very moment – and extrapolating – if you keep it for 60 minutes, you will be 80km away, but just keep it for 10’ and you’ll make 13km. What we really measure in scrum is speed not velocity. Maybe that difference can be a bit elusive at first sight, yet bear with me. The scrum “speed” tells us exactly nothing about how we are doing right now or what can be predicted for the next hour, day or week. Just consider the difference between “we are walking 5km per hour now” versus “yesterday we made 25 km, and the day before 27km”. Don’t the messages tell a different story?

I don’t try to convince you you should stop measuring nor I want to ban all forecasting and predictions. Just want to point out, you should not trust them blindly. Don’t get yourself locked into planning-daily-demo-retro-repeat, you are not in a hamster running wheel. Comfort zone is a death sentence to creativity. There are people who will try to convince you the numbers told them what’s important. Don’t forget it’s not the metrics, but their interpretation. And getting back to what I started, the most important things can’t and are not measurable at all! There’s no measurement of technical debt, there is no sum total of time wasted in hot-fixing the clanky old module that we have not time to rewrite properly. And nobody is keeping track of your personal burn-out factor. Keep an eye on your well being fellow programmer.

Everything changes

There’s one rule that never changes in programming: everything changes. And with all the credit given to current status of AI development, programming is still made by humans. All the time, we add features to an existing codebases or we modify the previous implementations. We also constantly refine our understanding and learn new things about our clients’ businesses and their needs. Worth to add, the code you produce is rarely isolated. A quite obvious thing, but I haven’t realised it for so long is that we write much less code then we read it. Unless you are really infallible in your decisions, you constantly read your own code all over and over again while writing it. 

Actually, I believe writing a new code is most of the time way easier than reading and understanding the existing one. Countless times, after spending too many hours in trying to untangle a “well-cooked spaghetti ball”, I’ve drifted away into madness of thinking “Yes, yes, let’s delete it all! Burn it to the ground and start from scratch!”. One lesson comes right now we should be writing what’s easy to understand.

In Mark’s words, let’s write code that’s readable for humans, not machines. Relax, they will get it eventually. Don’t ignore how the machine “thinks”, you definitely don’t want to loop through a five thousand element array inside the database transaction scope, but beside the obvious, please write the code that’s easy to read, easy to extend. You will thank me later! Let the compilers be compilers, and let’s not be wolves to our fellow programmers and our future selves.

We should focus on how we write the code and how it could be seen by other developers. One good rule is to try limiting the amount of “moving things” in your code to not overpass the amount of 7. It seems that 7 is the limit of concentration that most humans can simultaneously focus on and still remain comfortable. Like this joke, about the function input parameters. If you already have 7 input parameters to your function, it probably means you still forgot about 2 or 3 more in there. Let’s keep things simple, encapsulated, single responsible and you know what I mean…