This is mostly an introspective article: since I’ve been a software engineer for several years now, lately I thought back a lot about my history in this field, pondering about how time and experiences have shaped myself. This introspective process has been greatly helped also by looking outside myself: relating to other software engineers that I worked with acted like a mirror for these features of mine that are hard to see from the inside.
I gathered several insights from this introspection: here I’m going to list some bad habits that I had (or I have) to overcome in order to shake off my immaturity in the software engineering craft.
1. Using the language incorrectly
Software engineering in Italy however English knowledge is rather poor and it’s not uncommon to find software engineers that aren’t able to use such language properly. The result of this combination is source code and documentation (if it’s written at all) cluttered with English expressions suffering from bad syntax (that’s bad) and/or bad semantics (that’s worst!). For example I saw several times the word “design” being translated with “disegno” (that’s actually the word for “drawing”), instead than “progettazione”. You don’t draw a software with a pencil, you design it! 😉
Actually, at least here in Italy, the improper use of English is a problem involving several other fields (e.g. politics, marketing, economics); my impression is that this is just the natural evolution of Don Abbondio’s “latinorum”.
**MYSELF: **actually I’ve always been a sort of “grammar nazi”; since I think that this is a good thing, in order to not praise the nazis, I’d rather talk about “careful writer”. 😉 Anyway I had to undergo several troubles before mastering the English language decently: I remember vividly how I used to wonder things like “is it length or lenght?”; that was almost 10 years ago, anyway.
2. Coding right away
This is a classic: you learned some coding skills, you feel greatly empowered, so whenever you’re faced with a software project you jump straight to the code. After a while, you may find that the craft is much more complex than you thought and that you took a wrong road, so you think that you’ve got only two chances left: rewrite it from scratch or keep coding your way out of this mess.
I think that probably every young software engineer has experienced such scenario. The hidden sin here is the lack of analysis and design. Software is a strange beast: you may find it in boxes, containing a DVD or something like that, but every software engineer knows well that it’s only a shell for the real deal, the bits. What most of software engineers miss, instead, is the fact that the bits themselves (well, the code, actually) are only a representation of more abstract concepts. Software could be defined in several ways, but it always has some kind of structure and some sort of behaviour. These two characteristics are often overlooked in the hurry to write some code, but they always manifest themselves. As a software engineer you have two ways to deal with them: dominate them or be dominated by them. To be dominated by them it’s easy, as I’ve already explained: jump straight to coding and let structure and behaviour manifest themselves later (and be sure to get big troubles). In order to dominate structure and behaviour you have to think about them beforehand: you should first analyze the problem that you must solve (problem domain analysis), then you should start thinking about the structure and the behaviour of your beast (pardon, your software) in order to adapt it to the task at hand (this is the “design”): for example, this involves finding out where it’s most likely to change in the future; in general it’s about making choices about your software structure and behaviour to make them fit the problem at hand. If you code right away, you’ll often overlook such high level choices, ending up with a “self grown” solution that’s most likely inappropriate. There are several ways to do analysis and design, but if you don’t do them you’re doomed.
MYSELF: been there, done that… Actually I’ve done the mistake to overlook analysis and design at the very first time that I wrote a software for a client (that was paying me!). As a result of bad structural choices I had to rewrite it from scratch. While this was a bad thing, it also was the occasion to start using Alex Martelli for the hint!); but mostly it was an eye opener about what the software engineering craft it’s really about. Lately, when I do non-trivial softwares, I’m always careful about remembering to do analysis and design; anyway I still happen to stumble upon software projects that are already in progress and deemed to fail because of this mistake (it happened in my last job, for example). It’s really bad, I hate it.
3. Over-structuring
This mistake is often the consequence of the realization that coding right away leads to bad consequences: the realization is so shocking that, instead than starting to think sanely about what’s above the code’s level of abstraction, some software engineers get really paranoid about this. The panic fosters an irrational search for a sense of security by over-structuring their software projects. The problem here is that, instead than finding a design that fits the problem at hand, they build complex structures that are always overkill and most likely also off-target. As I said before, also, structure is only one half of the nature of software: over-structuring often leads to overlook software’s behaviour too.
MYSELF: while I’ve surely been affected by the “over-structuring syndrome”, it has been only in the University context, when I was being exposed for the first times to the OO concepts. In my case, more than paranoia, it was caused by the euphoria of finding out some interesting concepts (inheritance, anyone?).
Conclusions
I just highlighted three bad software engineering habits, gathered from my personal experience. There are surely quite a lot of others (e.g. not writing documentation when needed… or, maybe, even writing introspective articles is a bad habit? 😉 ) but I think that even just remembering to overcome the three habits that I mentioned is a big leap toward the mastery of software engineering.