In all advices we receive as software programmer, one of the most misunderstood (just after don’t repeat yourself) is don’t reinvent the wheel. Of course, it seems pretty obvious that if we re-do everything all the time, the whole industry won’t evolve at all. But when we dig enough, it is clear that all of us do not have the same definition of a wheel. I would like to explain here that defining what needs to be re-do in your context might be harder than it seems.
The usual suspects
I often hear this argument for 2 main software parts: some User Interface (UI) component and the Object Relational Mapper (ORM). For the UI this is usually used for complex grid with advanced features like filtering or advanced search for instance. The ORM is this magic piece of code that let you manipulate data in a database without even think about it. In both cases it seems perfectly reasonable to suppose that it will accelerate your development workflow to use them. Because after all your job is not to fetch data from a database or even to display them in a nice filtrable grid.
The success stories
I do not have any scientific data to demonstrate what will follow, and I admit gladly this is just gut feeling. I’m ready to bet though that many of you may have done the same experience. You use the awesome UI component, and you’re able to deliver in production pretty fast. You can impress the stack holders during the demo thanks to many features in the UI. Most of them won’t be used but you know, who can do more can do less! The story with your ORM is quite close, everything is working and you didn’t write a single line of SQL. Database migration is automatically handled and you don’t need to know how it works. How glorious is that? This is by the way where most tutorials stop you’ll have to discover the rest by yourself.
The limit of the approach
One morning a user calls you: “I don’t understand why it’s so slow since the last update?” The problem is that you don’t know either, worse it’s not that bad on your machine. A few logs and search later, you nailed it, one of the queries tries to fetch 80% of the database just because someone in the code try to get some unrelated data in a weird way. Weird in a SQL point of view, but not that weird when your ORM hide it for you. And then you have to understand how it works under the cover in order to avoid the normal behavior of the ORM. It usually leads to untestable code in order to achieve your goal without performance issues. Soon after that, during the next spring planning, the users will ask for a “minor” UI change in the way we can filter data. And again, you will need to understand what’s under the cover in order to understand how to change it according to your user’s wishes. But the thing is that the theory of the framework will probably not match your program’s theory. And it will take a lot of hacky code and long hours of tests to make it work. And this is without talking about the bugs (or misuse) of the libraries you’re dependent on. It could be quite long and frustrating to wait for other developers to fix a behavior important for your business.
So what’s a wheel?
To be fair, it depends on your context, and project maturity. But basically, a wheel is something that is becoming a commodity through time (Wardley’s map could help to see and understand that not everything can become a commodity). Most famous examples might be electricity, the internet and now cloud computing. Of course you certainly not need to build your own database, and not even to host it. But thinking that you can build a complete product by using mostly existing libraries and frameworks is also a myth. Using other libraries to build a solution faster can make sense when you’re exploring a problem. But at some point, you probably need to replace them with custom components where you can have a complete control. This “inflection” point is hard to find, and most companies fight to keep things as they were instead of looking to what will be required at their maturity stage.
A software wheel is something that you don’t need to care about, in your context and at your level of maturity. Hence the hard part is that it will change through time. Try to keep an eye to understand where your bugs come from and what part of the code is harder to maintain. It might require to change “a wheel” by a custom part to take full control of the behaviors.
A few days ago I asked you to think about how to define your job as a software developer in a single sentence. This question is highly correlated to the question of what’s programming. That’s why an article on the matter was pointed to me on twitter in response to my tweet on software developer’s job.
Looking for Naur’s programming as Theory building will lead you to this article.
It was written by Peter Naur (the one from the Backus-Naur Form, aka BNF programming language syntax notation) in 1985, and it is so far one of the most comprehensive texts on what’s programming I had the chance to read. To quote him, a motivation “of the presentation is a conviction that it is important to have an appropriate understanding of what programming is. If our understanding is inappropriate we will misunderstand the difficulties that arise in the activity and our attempts to overcome them will give rise to conflicts and frustrations.” I could hardly agree more.
Programming and the programmers’ knowledge
The main point of the article is that a programmer (and her team) somehow build a theory of the program when working on software, and that this knowledge cannot be totally embedded in documentation and/or code quality. Actually, the fact that different developers will build different theories explain why we will always find a codebase we have to maintain from someone else “bad”. This is independent of the code quality or documentation unfortunately. “The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them.”
How to treat the programmer
One of the main impacts of such a view is that developer cannot be the disposable we would like them to be in an industrial process. Quite the opposite, they will appear as key part of any success stories in the software industry. “At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education. On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part.”
What’s a dead program
If we acknowledge that the team building the product is so important, it follows that the life and death of a program is not defined by the fact that it runs in production, but by life and death of the team building it. From that we can suggest that methods like pair and mob programming are must have for a long living program, because it will help the theory of the program to be distilled continuously through the team, and it will address the training of newcomers to know the existing theory.
“The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.” […] “What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory, so as to be able to become familiar with the place of the program in the wider context of the relevant real world situations and so as to acquire the knowledge of how the program works and how unusual program reactions and program modifications are handled within the program theory.”
And much more…
From my perspective, this article also gives insights about writing small replaceable features instead of huge monolithic one, on the importance of unit tests and on the reason why software development can’t be handled like an industrial process. But as Florent Pellet recalls me recently, it’s always dangerous to interpret past writing with our current context and understanding. Still, this paper is older than me, and it seems to me that it embedded many visionary wise knowledge that is absolutely not mainstream todays. Do you have the same feeling about it?
Because you’ll have many family’s meals in the upcoming days, it might be a good idea to train yourself in order to explain your developer job to the mere mortals in a single sentence. It may avoid the classical “can you fix my printer” or “can you check my wifi” issues. So before reading the rest of the post, stop for a while and try to think about it.
I had the chance to talk about it recently with other developers of HackYourJob’s community, and it makes me realize that “In order to explain it to a computer” cannot be the goal. This is just a means. So here is a more recent attempt.
Of course the interesting thing in this thought is not the tweet by itself, but the corollaries it implies.
My job is to understand someone else job
Let’s consider this to start with. What would be the primary skill expected by someone who needs to understand someone else? Hint: I don’t believe that any technical framework will help for that. So, what if programming was a social activity? Yes it’s important to argue that programming is not about being lonely in front of a computer. It might be a part of the job, but certainly not the hardest one. Understanding someone else means that empathy, being able to learn fast and understanding business contexts are keys to be an efficient programmer. The best program you can write is the one you do not need to write because you found a better alternative for the business to improve without a costly software solution.
My job is to explain someone else job to a computer
Computers have this particularity: they do not accept ambiguity. It means that you have to be absolutely precise when you talk with them, in terms of syntax and content. Hopefully for the syntax, compilers, modern IDE and search engine will help you. Contrary to what juniors or people outside of this industry might think, this is the easy part. Not trivial, but pretty easy compared to trying to express without ambiguity a set of business rules (ie the content). Many people will argue that this set of rules, the so-called specifications, will be written by someone else so you won’t have to worry about them when coding. You will just need to translate. Spoiler alert: this is false. Even if someone else tries to do it, it will never be clear enough for a computer to understand it. If a computer can understand it, it’s called an algorithm, which is nothing but executable specification when written in a specific programming language. It doesn’t mean that having someone else to help you understand the business is bad, it just means that it won’t avoid the necessity for you as a software developer to understand the business.
My job is to improve someone else daily work
It’s tempting to believe that writing software is the ultimate goal of a software developer. Even my first tweet suggests that. But of course, software is only a means. You can write the best software in the world, if it makes its user’s life harder for bad reasons, you are still a bad developer in my opinion. Hence ethic for example is also a major component of our work. It also means that you can be an awesome developer if you improve someone else daily work with an excel macro. Don’t let the industry define you with technical languages and buzz words. The outcome of your job is much more than that.
How would you define your job in a single sentence?
In this post, I tried to express all corollaries implied by this simple sentence: “As a Software Developer I have to explain someone else job to a computer in order to improve someone else daily work.” What are your propositions to improve it? Or maybe you don’t agree with some of the corollaries? Or you think I missed an important part of the job?