Technological Thoughts by Jerome Kehrli

I am really amazed and astonished by a few updates I've been seeing on linkedin recently.

I've been working these ten last years with incredibly gifted people. You know, the kind of guys you discuss with wondering whether you yourself will ever be as good, clever and keen as them. I really think being that good is nothing to be ashamed of so let's assume I can name these guys. The very first one I remember is Thomas Beck (Geneva, Switzerland) . I've been working two years under his supervision (he was the software architect on our project) and I have learn more about the job discussing with him than I ever did reading whatever software architecture or design related book (agile, DDD, whatever). Happily I have learn a lot more since I left him yet I'm quite sure he did even more so I believe I'm still far from reaching his level of mastering of the software architecture business.
Other people I would also mention here are Sebastien Ursini, Sebastien Marc and Thomas Caprez (Geneva and Lausanne / Switzerland). I haven't seen these folks since several years for some of them yet I can still pretty clearly remember what they taught me and there's not one single day where I don't benefit from these teachings in my job.

On the other hand, just as everybody, I really had much more often the occasion to work with terrible software engineers. I principally encountered two categories.

The first one is this kind of people that went to great engineering schools or universities and assume the time they invest in their studies is well enough and exempts them from providing any little additional effort to keep learning since they graduated. These people are fools believing they're great only because of some piece of paper assessing they have once been able to learn something. I hope all my very good french colleagues won't hate me for this but I have to say that specifically french engineers are subject to this bad tendency.
Unfortunately, life doesn't make any gift to anyone and most of them are sooner or later taught the hard way how they're wrong and start kicking their buts to actually start learning the job and make some progress.

The second category is way more dangerous. This is the kind of people that sell themselves as software architects without any real software development experience. These folks read lots of books, follow lots of software architecture blogs and assume that this exempts them from building their own experience before claiming being software architects. I'm not saying reading is not good, but I am pretty sure that it is in no way comparable to experience. Unfortunately, due to poor recruitment processes one one side, and the lack of good software engineers on the market on the other side, these guys manage to find a software architect job and end up taking architecture-level decisions.

I am involved in the recruitment process in my current company (just as I was in my former companies). I take care of the technical assessment. I myself am usually a nice guy (well I think) and yet I show no mercy to candidates. I am pretty well aware that a mistake I make in this process might well lead me to work with bad engineers a few months later and this is a risk I'm not willing to take at all.
I am the guy killing those people. When I see someone coming in front of me with a resume claiming several years of experience in software architecture and not able to answer correctly the very first questions I'm asking him, it usually puts me in such a bad mood that I still keep the guy for the two hours that were planned and bury him 7 feet under ground. Hopefully the guy will work on a resume a little more humble before applying to another position (in another company, needless to say).
Just a word on "answering correctly": there is usually not only one good answer to a design problem or an architectural question, neither do I expect one. But I expect the candidate at least to build a proper conceptual model of the issue I'm presenting and to be able to outline a few solutions.

Now why am I putting all this online ?

I've seen it once more recently. A guy who has only a few years of experience as a software engineer, who did not even only once write a complete software application from the grounds up and put it in production and who is involved in design and architectural level talks only for a few months has just updated his linkedin profile claiming he's a software architect with 7 years of experience in software architecture.

First I needed to react to the huge disappointment I felt seeing someone I know quite good falling in this pitfall.

Then, I just want to warn you guys. Don't mess your resume up. Don't do that.

Don't put any single word on a resume that you cannot fully explain or that you cannot 100% defend and assess. Be prepared to be challenged on every piece of technology, language, library, toolbox or software you claim to know. And count on the guy in front of you to actually master these technologies or languages. Don't put library "abc" in your list of specialties unless you are fully able to discuss the advantages and drawbacks of this library as well as the related programming tricks as far as the bugs it might have and may need to be worked-around.

Now regarding software architecture skills, this is a raw list of some of the subjects I believe a software architect claiming several years of experience should be well aware of, presented as they come in my mind: most common design patterns (GoF at least) and anti-patterns, most common architectural patterns (Folwer's EAA is a start), 4+1 Kruchten views, ADLs, SoC, non-functional requirements (quality attributes), an idea of the various definitions of software architecture, the stakeholder theory, security principles (DiD, etc) and lots of various other topics.
In addition, IMHO a software architect should master the most essential programming techniques such as OO design (OO principles, how to apply them, advantages, etc.), functional programming principles (closures, curried functions, etc.), concurrent and parallel programming (usual models, Amdahl and Gustafson, communication patterns, synchronization patterns, etc.). Of course I expect a software architect to be well aware of how these principles or patterns apply in the current usual technologies or languages and to be able to discuss the advantages and drawbacks of each one over the others.
For instance, a little programming trick I enjoy discussing during interviews is the double-check locking pattern in Java, does it work out of the box, how to make it work, etc. ?

Finally, a software architect should be able to decide what technology is best for what piece of the software. Should it be a Web app, a mobile app, why ? Why not ? Should it run on Windows ? AIX ? Why not Linux ? Should it be written in Java, C#, Scala ? Why ? Any other language ? Why does it need Oracle or DB2 ? Why is PostgreSQL not sufficient ? Or is it really not ? And to defend these choices considering not only functional stakes but each and every non-functional requirement such as scalability, certifications, editors guarantees, etc. as well.

Let's face it, I cover here just a very few of the topics I expect a software architect to master. So think twice before claiming experience in software architecture when applying to any software engineering position. There are good chances that the guy in front of you will challenge you way beyond what you expect. Missing a good job in you dream company because of some excessive arrogance on a resume seems quite stupid.