I had just signed up to a course called “Software engineering”. I am not going to lie. I had heard the course was a walk in the park and given that that semester I was about to overexert myself with some tough modules, I decided I would take this one to balance it out. Hey, I didn’t want to be a software engineer!
However, software engineering laid the basis for a thought process defined by diligence. It might be the single most useful class I took. Software engineering was building on First Order Logic to formally specify a programme. Describing a system formally was without question the most pedantic, boring and useful thing I have learnt. See, Computer science, is a “made up” science. It’s based on (boolean) math so all good and well here but, unlike physics, it’s not bound by the laws of nature. Everything goes. So when you need to define a system you have to explain the tiniest assumptions you’re making.
Take this simple example from the actual class:
Phrase: Italians only read Topolino.
Formula: ∀b:books, ∀p:people. [(italian(p)∧read(p,b)) → b=topolino]
The phrase sounds simple but the Formula, which says the same things, adds details that seem obvious to the human mind but not at all to a database or a compiler. So to be more friendly to a computer, it reads something like this: “For every b, where b belongs in the set “books”, and for every p, where p belongs in the set “people”, if p is Italian AND p is reading a b, then b must be topolino.”
The first time I saw this in class I was beyond boredom. I could not comprehend what I had gotten myself into. I would have to spend a semester detailing in the same fashion very complex systems in the most expansive formal way to preclude any unexpected scenarios from happening and to ensure that the system behaves **exactly** as we want it to. Sigh.
But with such rigorousness come advantages. Things are deconstructed to their essence. The designer is thus forced to describe with precision not only what (s)he wants but also what (s)he wants to avoid, which is super important – imagine medical applications -. Using any program without having conducted formal specification is analogous to living in a building which was built without a structural engineer first describing the structure of the building. Would you live in that building?
But besides ensuring robustness, formal specification comes with another benefit, with broader applications. Specification forces one to be precise in their speech. And in product management where I have spent my career*, speech is a very important tool. See an engineer’s job is not to guess what the PM thinks or what common sense would dictate. That is most definitely not the job of the user either. So, when you write a user story along the lines of “As a user X, I want to do Y so that Z” you are writing a similar phrase with the one in the example. And when you proceed in defining acceptance criteria – given a user is in state A, when user does even B, then C- you are really writing the formal specification. Being trained in the formal notation is training your mind in set theory, in being able to ensure what events belong in the sphere of possibility and which ones do not. This is the skill that guarantees non-buggy products and happy users.
And of course, this extends beyond product. In life, in relationships, in negotiations and most importantly within one’s mind. Being precise when structuring one’s thinking is the single most important optimization that I can see. It’s impact spans from from increasing happiness (be clear what you want, what you fear etc) to achieving and enjoying success (first be precise what success is and what is not – then you can have a fulfilling result).
So, software engineering. Take that course. It’s not about programs, it’s about precise with your words.
Notes:
* I see entrepreneurship as product management with a couple of differences. Higher degree of autonomy and more admin.
MTsireud 