in Software Engineering

Architect – Overrated!

  • You always talk about the big picture.
  • You think you know how the system ought to be built.
  • You are unhappy that the team is not executing your ideas the way you want them.
  • You don’t have a working build.
  • You spend a lot of time on documents that are not code.
  • You can prototype – but your code is not production worthy.
  • You spend too much time in meetings.
  • The best code you wrote is a few years old.
  • When asked for opinions you tend to speak in general terms.
  • Your team members secretly joke about you.
  • You start to take analysts and tech blogs too seriously.
  • You are a dinosaur.

Code. Don’t wiki. Don’t powerpoint.

Write a Comment



      • I agree with your “architect must be best in team” point.

        However, I’d like to throw the top notch summary phrase “Code. Don’t wiki. Don’t powerpoint.” back on you.

        I wish you to read this blog again while trying to maintain some legacy agile system at about 2020. Then you’ll get an idea that having top-level documents (wikis, powerpoints, readmes) describing the architecture are not so lame.

        Read agile manifesto one more time just to make sure you were right and I was wrong. Write less comments. Code more. Viva agile!

  1. Far more true than many would like to admit, and definitely the general case … but on the other hand, I’ve seen cases where brilliant coders know a lot less about software architecture than they should, and lead the team by example into a crap-tacular product. Heck, I had a contract a few years ago where I was asked to clean up from such a mess (I failed – it was too late in the process and the damage was done).

    IMO, all architects must be at least good coders, and not all great coders should be architects.

  2. Subbu, I usually see these type of discource from people who do not understand the concept of ballance of powers as it applies to technology leadership in general and the role of an architect within it in particular. but you actually were a fine architect at the time I was in seattle and you were at Yahoo, so I am really curious what happened…

      • Exactly,
        The developers on the massive project I’m on work in a vacuum. The architects are always somewhere architecting, but there is no leadership or direction where the code is being written. Therefore, the position is useless.

        We are all here fending for ourselves. When we invite architects they are ‘too busy’ to attend. We are left creating our own solutions and answers. Most people here have been here less than a year and have no clue what is going on.

  3. I believe that in order to be a relevant and effective software architect one needs to remain a deeply knowledgeable, up-to-date, and productive software developer. Besides, keeping your hands on the keyboard is just more fun (even if you can’t do it full time).

  4. While I appreciate where these feelings come from, I think you would be better served by spending your obviously well tuned brain cells to the problem of…

    “How do I improve my relationship with my architect?”

    I certainly hope you emailed him this link to your post.

  5. While in the vast majority of cases I agree. On large projects however they are needed to counteract 1st line engineering managers. Who often have their team deliver and work on only tasks that the manager has been assigned as deliverables. Which is often in conflict with what’s needed for the project to succeed. Like the task x that nobody committed too but is critical. Or the managers agreed on an illogical partitioning of tasks.

    It can also be useful to have a technical track for developers that has levels up the Director or VP level. Not just for career growth but also for escalating serious technical issues up above any territorial engineering manager dispute, which happen more and more as the project size increases. There’ nothing worse than a whole group of 1st line engineering managers who all successfully completed all their tasks lists on time and boom a six month slip. Especially when the developers knew it would happen the whole time.

    You see these issues with really large releases like operating systems. Not so much with small teams. Nothing worse than breaking your but for six months on a project you know is doomed.

  6. It’s critical to have an initial design that is well baked as they say. When you have lots of groups from vastly different technical backgrounds working it can be difficult. It sometimes comes down to what unknowns/risks you are willing to accept. I’ve seen at least one project completely fail due to issues that could have been pointed on day one. But that was just a bad job or probably more a case of someone not realizing that they didn’t have the background to lead the design for that project.

  7. And I’m a C/C++ developer who has delivered at least one subsystem on every release I’ve worked save one. And I was switched to that project after it slipped and was forced to be the release manager (and I still fixed bugs).

  8. And if your still not convinced in the importance of good technical leadership… I worked at one company that would develop or buy two versions of the same product. By different teams of people, group A and B. Then after evaluating various metrics like performance, maintainability, performance against schedule, ease of adding new features, sales/customer feedback would choose a winner. Say group A. They they fired the entire “losing” team, group B. Which team would you want to be on? The one with good experienced technical leadership or the one where you had to hope that your engineering manager didn’t do performance reviews based on but kissing?

  9. Interesting point. I do not agree. I consider myself a software architect but I also contribute a lot of code to my projects (I often write the entire base/core to start with and often I write at least 25% of the total code / 5 members).
    I don’t wiki, instead I write inline documentation in the source. I don’t have any meetings; I only do ‘short presentations’ once in a while about the architecture. I teach, coach and explain ‘on the fly’. Also I am not unhappy with my team and I code actively every single day (mostly PHP, JS and C).

    You just haven’t met any good architects I guess.

  10. yes, i remember this one. how about this…

    You can’t see the big picture.
    You have no idea on how an inter-operative system is designed or built.
    You are unhappy that the team will not allow you to code alone in your own unique way.
    You have a working build that is so convoluted, no one can understand it.
    You spend all your time on code that no one can understand and you can’t explain it to anyone.
    You can’t prototype and every module you write is over-complicated.
    You never show up to meetings and won’t engage with the rest of the team.
    The best code you wrote is today — you keep re-writing the same code over and over to “make it better”.
    You can’t deal with anyone else’s opinion but your own.
    Your team members secretly complain about you.
    You start to take the latest code library releases and manifestos seriously.
    You are a cancer.

    the variations are endless, of course.