This morning I was interviewed about being a software architect from the point of view of the general public. I have copied the questions and the (raw) answers here.
1. Why do you like this profession (Software Architect)?
The software architect position is the best position for someone who likes to build things in software. It is an extension of programming. I always describe programming as: “solving puzzles as a job”. The best way to understand this: do you like to solve Sudoku puzzles? or crossword puzzles? Programming is like having a job where you solve those puzzles full time. Software Architect is a higher level job to figure out how to break the system up into smaller pieces that can be solved by individuals on a team. A Chief Architect divides an even larger system into pieces that can be solved by teams. It is not easy to find the right solution which has the proper balance between power and usability. The satisfaction comes when customers actually use and like the result – that is the best proof that you have found the right solution.
2. What training is required to be a Software Architect?
A thorough understanding of software engineering and system design principles is required. The principles that guide system architecture are not naturally intuitive. There are many things that an inexperienced architect will do to attempt to make the system run faster or smoother, which actually has the opposite effect when the system is scaled up to high loads. Today, a good understanding of object oriented design and service oriented design are required, but in my experience the inexperienced architect is most often tripped up by an incomplete understanding of threading and transactions. Funny thing is that it does not seem to matter too much which programming languages you know and use. Everyone has a favorite for a particular task, but it is fairly easy to switch between them, and the worst mistakes/performance problems are at a higher conceptual level and could occur in any language. So focus on understanding how systems work, and not just a particular language.
3. What advice can you share with others in or entering into this profession?
Prepare to be misunderstood by the public. Most people mistakenly believe that programming and system architecture is a kind of manufacturing where basic requirements are input, and the code is produced in a left-brained factory-like way. Software development is more like the fine arts than it is manufacturing. A great programmer is better compared to Michelangelo than to Henry Ford. The reason is that every day the software developer creates something brand new that has never been invented before. Once that puzzle is solved, it never needs to be solved again. There is no repetition. Contrary to public perception, software development is an extremely creative, right-brained activity. The clearest evidence for this dichotomy is that struggle for acceptance of an Agile method for development of software. Those who understand software development know that an Agile approach is key to good software, but traditionally trained management is very uncomfortable, and want instead to run things like a manufacturing plant. My advice is to learn everything you can about the Agile approach, and avoid organizations that do not employ it.
4. Do you feel you are you over/underpaid or paid just right?
The interesting question about pay in the software field is how great a variability there is in talent. A famous Harvard study found that programmers will vary in productivity by a factor of 18. Other studies have found factors around 20, and even one extreme study that found a factor of 200. What this all means is that what one developer will take a month to accomplish, another developer will complete in a day. There are people that if you can get them for 3 weeks, they will outperform a full year of the worst programmers. The interesting thing is that while productivity varies over a range of ~20, the pay scale varies only a range of ~1.5. That developer that is producing 20x, is getting only 1.5x pay. The lowest performing developers are overpaid, while the highest performing developers are vastly underpaid. Some simple math tells you that your best deal is to pay a little more, and get a much better developer. A small team of capable developers will outperform an army of weak developers every time. The industry as a whole pays the average developer pretty well, but gets a tremendous deal on the high performers.
OK, I admit, I pretty much dodged this last question. But who is going to say that they feel they are over paid? Saying you feel under paid seems too self serving. I came up with the most interesting answer I could. 🙂
Thinking Matters 
Very insightful and interesting interview! I especially enjoyed the answer you gave to that last question 🙂
You say that system architecture is more than just requirements input, and you strongly advocate the benefits of Agile Programming. Based on your experience, do you feel that most of the architectural drivers get to be correctly identified in the first iterations when using an Agile Software Development methodology?
Finally, i completely agree when you say that finding the right solution is never an easy task…like Thomas Sowell once said: ”There are no solutions. . . there are only trade-offs.”
No, most of the architectural drivers are not correctly identified in the first iterations. That is, of course, why you iterate. The customer can identify what they like when they see it, but in general they are not good at anticipating what they are going to like. So you have to build it before you have complete information on the goals of what you are building.
On your blog you mention experimenting with the recipe of chocolate cake. Your goals are clear: bake something that the customer will love. But you can’t really anticipate if an increase in sugar will make the cake more or less appealing. My intuition leads me to believe that adding sugar will make the cake sweeter, but it will also effect other aspects of the cake in ways it is hard to predict. Thus you can’t really ask the customer “would you like 10% more sugar?” It is impossible, to judge the recipe before it is baked. Instead, you have to try a recipe, and then have the customer judge the end product. The only way to experiment is to make many many versions of the end product. This seems so obvious, but it is surprising how many people have a hard time understanding this, and think instead that you should simply “design that cake to be right the first time.”
http://socialbits.eu/a-chocolate-cake-vision-of-bpm/
I am sure you know as well that BPM is in the same boat: you have to iterate, trying different processes in real lie before you know what the best process is.
Thanks for the comment, and good example with the cake!
First of all, thank you for the feedback and also for reading my post.
Outstanding the way you explained it using my analogy as an example: it makes perfect sense. The main reason i asked you that was because i don’t have many experience in large software projects or managing agile development teams, but i’ve always suspected that it is hard to get the architectural drivers right from the first iterations.
Relatively to architecture being in the same boat of BPM, i relate it better to the architecture of a BPMS allowing or not for business processes to easily adapt to the real life situations and requirements, than the experimentation itself. Just like you mentioned on the BPM2010 firechat session on ACM, Interstage provides formal business processes, but also provides ACM as a feature: it allows people to create new semi-structured processes and tasks during run-time. That flexibility is possible because Interstage’s architecture considered those concepts and features from the start, i.e., it considered the requirement of creating such entities as an architectural driver.
Thank you very much for enlighten me.
Pingback: links for 2010-09-29 « steinarcarlsen
Very interesting interview.
“Prepare to be misunderstood” – exactly my thoughts when I wrote on the difference between different types of software architects that is often misunderstood; and try to provide an analogy that also attempts to highlight the artistic nature of software architects (whether development architects or solution architects).
http://rraheja.wordpress.com/2010/10/01/architect-vs-solution-architect/
I appreciate what you posted. I’m 15 and I’m currently in a cyber art course in high school where we have begun to use some codes in programs such as as flash. I’ve always thought about being a software architect however I felt that my artistic abilities would be better suited else where. However I have a great love for computers and the programs that run them. Thanks to your responses I see how having great skills in art will go hand in hand with my love of computers if I choose this career path.