About seven years have passed since I started writing software for a living. For no particular reason, I’ve recently been thinking about the parts of it I’ve both enjoyed and been successful at, as judged by my bosses and peers1.
Software is not only about modeling the world, but it always involves some of it, at least when dealing with problems rooted in reality. This is also about a discovery: out of school, I really thought “all interesting ideas have certainly already been discovered, there’s not really much left besides implementing someone else’s and hoping they’ll pay me for it”.
I was misguided on multiple points: the one this post is about is that modeling existing ideas will always be required and will make good use of any creativity available to that task!
If you’re thinking I’m only good at, or interested in, solving other people’s problems, you still have a practically infinite playground for which you can get paid good money by just playing in it.
Start With A Model2
This may sound trivial, but in my opinion it’s one of the funny secrets of our profession. One of the simple methods that got me the best ROI, in term of praises, or any proxy thereof, over time invested has been:
- Properly3 model exactly what your business is about
- Update your model when it’s getting in your way
- Repeat
In concrete terms, this means taking the time to define structures, interfaces and so on that represent the things you regularly deal with (pieces of inventory, machines, types of IoT devices, animals, networks, you name it), as well as their relations4.
There is no need to be too pedantic about it, though most of the thinking should go into things that are harder to change later: that would mostly be about relations, because attributes are generally easier to change – at least when you add some…
Afterwards, don’t be afraid of updating your models when they’re not satisfactory anymore! Your business will evolve, you’ll have missed some details or overthought certain aspects, someone will suggest a different but better way of thinking about things, etc.
Once you have your model, you can start playing with it, or at the very least, start to tackle the problems that got your started with this in the first place.
Why would I say this is a funny secret? Because many difficulties I’ve encountered when joining existing projects were rooted in the absence of any of the two first steps above: either there is not even the crudest attempt at conscious5 modeling, or improvements upon the original model have ceased.
The Power of Abstraction
A good model is useful because it will provide you with a good abstraction. What you’re really doing when declaring structures, types and relations6 is to bring a certain aspect of reality across a boundary, from reality into the abstract realm that is accessible through a computer.
Whatever you modeled will be available in a world where insanely many things are possible: think about how having simple data in a spreadsheet opens up possibilities you can hardly even dream of when dealing with paper records. Then think about how a programming language lets you express many more subtle things than the spreadsheet.
This is where the fun can really start: once in this world where ideas and concepts can be freely manipulated, a lot of possibilities will appear effortlessly. Many of which you would have not even thought of in the first place, if you hadn’t taken the time to model things out.7
A computer, along with the ability and time to describe the world to it, are the only prerequisites to unlock this power.
A Fourier Transform Analogy
To end, an unrelated observation.
Although I might have been asleep during these lectures, at no point in my education (even during engineering school) do I remember anyone telling me:
“Hey, computers are awesome because they let you model the world and this makes them incredibly powerful!"
If I could convey that kind of enthusiasm to my past self I definitely would.
For example, this was done many times for Fourier Transforms. It was made clear to everyone “see, just transport things to this other abstract world where you can solve problems in a trivial manner and then bring back the answer, it’s extremely powerful8". There might be a missed opportunity here.
Even the most junior engineer can discover the transforms that are the most useful to their problem.
Happy modeling!
-
Using simplish heuristics such as: getting spontaneous raises, getting new benefits when I ask for them, colleagues praising my work, interns and new hires stating I’d like to do more of what you do and also, simply, not getting fired for doing certain risky things which did not always pay off9. ↩︎
-
Assuming someone already gave you a problem to solve. ↩︎
-
with a definition of proper along the lines of: You have a proper model when it helps you with answering your business questions ↩︎
-
That’s also why one of my Hard and Fast RDBMS rules states “Express as many constraints in the schema as possible” ↩︎
-
Any software that is solving a problem, however bad you might judge it, models some part of the problem. One form of badness in software is bad modeling and it’s independent of other forms of badness. A good model can still be implemented with spaghetti code. ↩︎
-
This is where type systems really shine, as they let you express tons of things in them and will tell you when you’re doing something inconsistent with your model. ↩︎
-
Note that with experience, developpers will be able to reason and discuss about such models in their head without writing a single line of code: the time between let me try to model things in this way and holy mackerel, this makes solving problem X and Y super easy increasingly shorter, increasing their potential contribution to a business exponentially. ↩︎
-
Obviously, mathematics, at least when used to model reality (or does that already count as physics?) already represents such a translation from reality into the abstract. This only means that there are many abstract worlds between which you can, quite literally, travel. ↩︎
-
Although, on that subject, I’m not sure that anyone else than developpers themselves have access to the required information to properly judge risk in most situations: they may know the relevant things but will often not understand them. This is an incredibly interesting subject I’ll have to keep for another day. ↩︎