Software engineers immaturity symptoms

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 lingua franca has always been English: most of the programming languages syntax reflects this fact. Here 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, did 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 Python (many thanks to 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.

3 thoughts on “Software engineers immaturity symptoms

  1. Proudlygeek Reply

    Hi Paolo,
    I agree with the fact that most of the italian developers can’t properly use english as their way to comment, document or more generally write something.

    I’ve recently started to write an english blog about programming topics (http://proudlygeek.appspot.com) and sometimes i find difficult to correctly translate some words/phrases without using a dictionary; i hope that keeping on reading, writing and speaking will improve my overall knowledge of the language.

    By the way, analysis and design are the most important phases in software engineering, but it seems that every developer should make this mistake at least one time in order to understand their crucial importance.

    Personally i’ve done a lot of errors and over-structurize is one of the worst: simplier is better, generally speaking; solve problems with only one paradigm and/or one design pattern is usually not flexible enough. I (painfully) learned that but still sometimes i’m tempted with the “code now, think later” phylosophy. It makes me feel a bad, bad person 🙂

    If you have some spare time feel free to check my blog (see above): it’s python powered 😉

    • Paolo Bernardi Reply

      Hey Gianluca. 🙂
      I am especially fond of the English usage because I had to struggle a lot to master the language (for some crappy bureocracy I had to study French in high-school… needless to say that I barely remember the fundamentals of it :-P). I think that you’re spending some energies very well while writing your posts in English (and, on a separate note, also while doing the K&R exercises… :-D).

      About the analysis & design neglect and the over-structuring, while they may seem opposite things, I think that they’re both rooted in the same bias: after you learn something you get that warm fuzzy feeling that you’re invincible. When you learn some coding you go right away with it, ignoring everything else; when you learn some analysis and design you over-apply it with the result of adding unneeded complexity (and the goal of A&D is really the opposite!). At least this is what happened to me, and I surely agree with you that this is an hurdle that has to be overcame personally by every software engineer. And both are recurring temptations. 😉

      From some time I try to avoid slipping into sloppiness to not make Dijkstra cry. 😀

      http://lemonodor.com/images/dijkstra-quick-n-dirty-s.jpg

  2. David Reply

    Although I am not a computer engineer myself, I feel that there is a common denominator between the science of computing and the right mastering of a habit (that is to say, developing a successful lifestyle).
    This introspective article perfectly highlights those bad habits that lead to the coding and release of bulky and over-bloated applications.
    Micromanaging is self-destruction 😉 Macro managing is the best way to get things done (correctly, and efficiently).

    You know what, Paolo? Introspection helps making errors visible! And errors made visible are errors you can correct with ease! You ought to write introspectively more often!

    see you,

    David

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.