Why I don’t believe in software architects (January 26, 2010)
A common train of thought in the employed hacker’s head: I enjoy hacking; I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship; but I still want to do some career management for myself. The option that seem obvious for him is to aim for becoming a software architect. If you ever found yourself in this way of thinking, think again, for there’s no such “software architect” job that you would desire.
On the first glance this seems wrong. There are dozens of open positions in software companies bearing this title. A quick search on Amazon for “software architecture” reveals thousands of titles. But first 50 results or so are dealing with the software modeling using some higher-level description language, which is usually UML, and sometimes more exotic choices are presented like Z Notation (anyone?). There’s even a book luring the described hacker into buying it with its title: Software Design: From Programming to Architecture (it is about UML modeling, too). The only exception is the useless collection of developers’ anecdotes named 97 Things Every Software Architect Should Know (carefully cached by Google here), but I tend to think that this is the exception which supports the rule.
But wait, shouldn’t software architecture be an activity which involves dealing with software itself and not the models of it? Book authors do not think so. I guess the reason for that is the fundamental dichotomy between programmers in different companies. A former colleague of mine wrote recently a piece on that:
From what I see, a typical Java-centered company is either a J2EE enterprise or a place where they care about util.concurrent. Amusingly, this seems to be a very clear dichotomy. In both cases, there is a pile of (de facto) standard APIs and frameworks which take considerable time to master. And people who gravitate to one of the two types tend to be rather apprehensive if not ignorant of the other
“J2EE enterprises” love “outsourcing-style interview questions”:
[…] an endless stream of extremely low-level technical questions on particular technologies and APIs. RDBMS isolation levels, the servlet lifecycle, the methods on EJB home/remote interfaces, JSP scopes. A design pattern for them is always one from the GoF book or Sun J2EE patterns guidelines. Characteristically, they do not care about your design skills or code quality and really like J2EE-style
For the recruiters or book writers “software architecture” is neither an activity nor a way of thinking, it is a way of determining the job title. In their reality “software architect” is the person squeezing 3rd party code into a conceptual software model. He clearly belongs to the J2EE side of the dichotomy though might not use J2EE at all. It is a person who values dependency on someone else’s software in favor of developing it. This sort of dependency may be good, but for the demanding subject domains this is a double-edged sword (Paul Graham covers this issue with his usual bias towards Lisp in one of his essays). The reason behind all that is simple: “architect” does not write code. Mr Joe Hacker, is this the career path you were dreaming about?
A curious reader might ask: why do you proudly claim to hold this title then? Because I believe in software architecture as a way of thinking. I see this as a capacity to deal with the huge problems and significant amounts of code nip and tuck with the in-house development team. I do even know a single good book on the subject: Eric S. Raymond’s The Art of Unix Programming. Even is you never will hack Unix, this is a very valuable book to read.
What about career path then? Well, I can’t give any personal advice here except for the “avoid advertised ‘software architect’ positions”. The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about.
Careers in cinema (December 27, 2009)
I had a chance to see recently released A Prophet during this year’s Viennale in November. The movie was a true gem of the festival (you should go and see it if you haven’t already), and one of the brightest glowing thoughts about its plot that lasted longest in my head was how rare the career building — enduring, inpredictable, life-consuming process — is reflected in the mainstream cinema.
For those who hasn’t seen the film: Malik, a 19-year old Arab is sentenced for six years in prison. He starts as a dogsbody for the Corsican mafia boss, then becomes his deputy, strengthens his own influence outside of the prison, initiates the clash between Corsican and Arab crime groups, and when Arabs take power becomes a leader of theirs.
Leaving apart the dubious “romance” of the criminal world, this sounds like the story of successful career. It involves significant amount of luck (the episode with the deer), quick wit, gut feeling for what takes priority at any moment, ability to infuence and negotiate, and stamina (when I see Malik following Corsican’s advice to be a “good prisoner” after Malik was taken under his protection, I can’t help but imagine junior lawyers in the firm doing the most boring due diligence tasks in the course of their first three years.) Huge number of people commit themselves to similar but lawful path in the everyday life. Sure, careerists do not risk their lives, but the stakes are high anyway — after talking to some successful New York traders, I guess I do understand what “high” means here. When looking at the story under this angle, I wonder why there are so few movies around covering someone’s career in the making? Sure, we have Pollack’s The Firm and Soderbergh’s Erin Brockovich and some other pieces where the door of personal office is opened for the protagonist to his biggest surprise, but unlike A Prophet those are not the stories of steel being tempered.
Someone might say that a story like this would not be captivating? Doubt that. What was in Jérôme Kerviel’s head when he entered his office at Société Générale every morning? Did the Gap’s manager who issued abortion policies for their labor force in Bangladesh get promoted? They all build their career. Unlike Malik, they join an “invisible graveyard”, but please filmmakers tell us about those who has survived.
PotD: Raoul Hausmann (December 12, 2009)
ABCD (Self-portrait) by Raoul Hausmann (1923-1924)
Administrativia (2) (December 8, 2009)
This blog will undergo some mutation. I started it two years ago as a part of the efforts of promoting myself as JAIN SLEE telecom consultant. This worked and I got some of the most useful contacts via this site; but I am not pursuing this goal any longer. Instead, I am focusing on becoming a better software engineer in the most general sense of this word, a person who could solve large-scale real-world problems in more efficient, elegant and concise way. The content of the relevant permanent sections of the site (see sidebar) is reworked too.
If you’re subscribed to this blog’s feed expect more entries of general interest soon; “100% telecom” mood has been left behind.
5th Fraunhofer FOKUS IMS Workshop 2009 (November 23, 2009)
A few days after this year’s Fraunhofer FOKUS IMS Workshop has been closed, let me tell about my impressions. This was the last year of the IMS Workshop in its current form; as FOKUS’ head, Prof. Thomas Magedanz has put it, “conference scope grows and ‘IMS’ start being just an umbrella term”. It is very likely that the event will continue further as a series of conferences showcasing FOKUS work.
Just like the last year, the conference has attracted participants from top telecom companies and standardizing organizations from all over the world. Interesting enough, the main focus of the conference has shifted. Instead of the walled garden, as some critics nicknamed the IMS architecture, most of the discussions were about open APIs of different sorts. From Deutsche Telekom’s Developer Garden (this very interesting and ambitious project aiming to provide paid access to DT’s infrastructure for developers has been rolled out in just around a year) to BONDI (attempt to standardize device API to give developers unified access to the device’s resources): different projects showed a great amount of interest in acquiring third-party developers. This trend clearly shows that the future of the telcos’ NGNs and the set of services they are to provide will be determined by community of developers or by ecosystem of startups supported by telco, and not by a telco itself.
Not only the openness was the hot topic. Over the years FOKUS shows the ability to respond to the industry needs in a very flexible manner. For example this year among the technical demos was the full-blown IaaS/PaaS solution. The virtual slices hosting FOKUS’ OpenIMS were moved around, resized, and reconfigured on the fly. As IMS itself (I will cite Prof. Magedanz again) became “vintage in regard to real research challenges, although there are still a lot of open deployment and integration issues”, the mentioned FOKUS solutions are capable of providing the base for necessary “openness” and “flexibility” of the future telecom.