Software Architects Suck – Never Trust A Software Architect

If someone’s job title is “Software Architect”, that’s a huge red flag. If they add extra adjectives, like “Chief Software Architect”, you are almost guaranteed to be dealing with a highly skilled liar.  In a 10 person business, you have an exaggerated sense of self-importance, if you call yourself “Chief Software Architect”.

Whenever someone calls themself “software architect”, that means “I’m a full-time manager. I write specifications and design documents. It’s beneath me to get my hands dirty and write code.”  This is an excellent arrangement for evil people.  They never have to implement anything, so other people can always be blamed for failure.

A small startup or small business does not need a full-time manager.  The head programmer should also do a lot of implementation.

An unqualified loser likes to spend a lot of time gathering requirements and writing specifications and documentation. That creates the illusion that he’s doing useful work. If you’re writing documentation and not code, you’re never responsible for failure.  Bureaucracy enables unqualified people to pretend they’re accomplishing something.  The software architect adds a lot of paperwork to the software development process, so it seems like he’s doing something useful.

The software architect says “I’m a brilliant leader! I’m managing a 10 person team!” According to sane logic, the value of a manager is the amount and quality of finished product he ships. According to parasite logic, the value of a manager is the number of subordinates. According to parasite logic, it’s better to manage a 10 person team than to manage 2 people and get more done.  It’s better to have 2-3 people delivering working code than having a 10 person team that ships garbage. In software, if you hire the right 2-3 people, they will outperform a team of 10-100+ people.

I went on an an interesting interview. It was a complex but routine bit of financial software. It was complex due to the laws and regulations the software needed to follow. It was routine “convert data from one format to another and do basic arithmetic”, with some customizations added for each customer.

Based on the description of the product, I thought “I could implement this by myself in 3-6 months.” The software architect said “I’ve been working with a team of 5+ people for 2 years. Beta version 1.0, with only 10% functionality, will be done in 6 more months.”

I’ve heard that one before!  The software architect is making excuses and delays, to cover up the fact that he mismanaged the project.  Even if he does eventually finish, it will be at greater cost and lower quality, compared to doing it right.

For my successful rewrite projects, the instructions were “Here’s the source code.  Write a cleaner version with the exact same functionality.  Then, we’ll add improvements.”  I didn’t need to spend a year gathering requirements first.  I read the code, listened to an explanation of the requirements, and then started working.

The software architect said “For the first year, I did nothing but gather requirements.”  Immediately, that’s a huge red flag.  He should have been simultaneously understanding the requirements, and implementing.  It doesn’t take a year to understand the requirements!  If you write self-documenting code, you don’t need a lot of design documents.  The software architect said “I spent a year gathering requirements!”, when he really meant “I spent a year drawing a huge salary, while I created a bunch of paperwork to provide my clueless bosses with the illusion that I was making progress.”

I’ve successfully completed “convert to new language and update” projects many times. I’m confident in my estimate, “I could do this by myself in 3-6 months.” Some people say “Never rewrite!” In this case, the old system was a mess of MS Access, and a rewrite is necessary.  They want to switch from a desktop application to a hosted version, which also requires a rewrite.

The software architect had taken 2+ years for a 6 month project. He still wasn’t done!  The delivery date for beta 1.0 was still 6 months away!  He was planning to finally deliver, albeit a limited partial feature version.  He was proposing that version 1.0 only met 10% of the requirements!

It was a 4 person interview. There was the software architect, another programmer, and the 2 owners. I could see the dynamics. The software architect was thinking “Uh oh! FSK is too smart and experienced! I need to think of excuses for rejecting him!” The owners were thinking “FSK is smart! I should hire him!”

After the interview, the architect will edit the owners’ memories so they will think I was a bad candidate. He’ll emphasize things like “FSK doesn’t have enough ASP.NET experience.” or “FSK doesn’t have enough front-end experience.” When there’s a laundry list of 10+ requirements, there’s always something to nitpick when you want to reject someone.  I have a lot of MS SQL experience, so that was hardly mentioned at all during the interview.  There’s also the classic “bad cultural fit”, when you make excuses for rejecting someone.

It was a classic productive/parasite dynamic. The “software architect” snows the owners with excuses, while he wastes their time and money. He produced a lot of specifications and documentation, but little working code. He managed the owners’ expectations, so that version 1.0 only needs 10% of the features, after 2.5 years!

That happens in nearly every single software business I’ve seen. A highly skilled liar is a manager. He will block any attempt to hire more competent subordinates. He makes excuses to his bosses while wasting money and earning a high salary. That probably happens in every industry, and not just software.

That’s the reason the economy is falling apart. Skilled liars get promoted to management. They won’t hire any competent subordinates, because they’re insecure about their own jobs. Competent rank-and-file workers are needed to get the job done. In a large corporation, the high-ranking management is criminally insane, so evil middle managers are “optimal”.  An honest middle manager would be “a bad cultural fit”.

On that interview, it was a small business. The owners didn’t have the emotional strength to resist a highly skilled liar.  I felt sorry for them, that the software architect wasted their time and money.  Given that the owners were easily manipulated, if they didn’t have that guy robbing them, it would have been someone else.

However, the owners did seem to be reaching their tolerance limit, for the “software architect”. Did they notice he had taken 2+ years, and was only delivering a tiny fraction of the rewrite?

Even if they do fire the software architect, they’ll probably hire another skilled liar, instead of someone competent. Even if the software architect gets fired, he’ll say “I have 5+ years of experience as a software architect!”, and he’ll find another host to leech.

A “software architect” is never expected to code himself, which makes it hard for management to find out he’s a clueless twit.  He can keep a job for years while making excuses to his bosses.  There’s always a subordinate to blame for failure.  When they get ready to fire him for his incompetence, the parasite moves on to another host.

I can see a huge conflict, if they do hire me. The software architect will see me as a threat and competitor, rather than someone who’s there to help. The software architect will say “FSK is not a team player!”, when I point out the mistakes he is making.

The rewrite project is probably a disaster-in-progress. It’s probably better to scrap it and start fresh, rather than try to fix the architect’s mess.  I’m pretty confident in that prediction, even though I haven’t seen their code.

Maybe if the owners reject me, I should propose an alternative? “Hire me to do an independent version of the rewrite. That is a hedge, in case the other team fails. Your only cost is my salary, but you get a 2nd chance to succeed.” Working with the incompetent architect can only lead to conflict.  During the interview, I could see him trying to come up with excuses for rejecting me.

“Software architect” is job role specifically designed for evil people.  All the people I’ve met who called themselves “software architect” were unqualified to write working code themselves.  They can’t get a job implementing, so the only way they can survive is as a full-time manager.  They promote the myth that software projects need an architect, so they can have plenty of victims to fool.

All the “software architects” I’ve met were parasites or psychopaths.  A successful “software architect” hires skilled subordinates, lets them do the work, and takes credit for their efforts.  However, most evil people are not smart enough to do this, seeing the competent subordinate as a threat to their own job.  In a large corporation, middle management must be evil, because the senior management is criminally insane.  In a small business, a highly skilled liar gets a job as a software architect.  He emotionally manipulates the owners, making excuses for delays and failure, while squandering their time and money.

7 Responses to Software Architects Suck – Never Trust A Software Architect

  1. What you say is very true.

    Years ago I joined a company with Software Architects. Years had gone by and all they had was a pile of silly documentation that didn’t make any sense. Their group was only architects writing documentation and no software developers.

    When a real software developer joined their group he was horrified. All their documentation produced over several years was meaningless rubbish.

    In the end the manager (an ex-software author from IBM) bad-mouthed the Software Architect and he left the company feeling rather pissed off.

  2. Using the word architect/architecture is one of my many pet peeves about software. Programming and code are not analogous to Architecture and buildings. Believing that is the case leads to all sorts of distortions of reality. The only time “start from scratch” is guaranteed to be an anti-pattern is if it is performed by the same team. I hate the term software “Engineer,” as well, its not like traditional engineering. If it is analogous to anything its handmade craftsmanship. Like handmade sculptures, plans are highly useless in this context.

    • It’s even worse for that interview. The “architect” will block the employer from hiring me. I could do the rewrite project by myself in 3-6 months.

      If software was like constructing buildings, half the projects would fall or never be completed. You would have missing doors and extra windows and missing stairs.

      It’s like a shibboleth. On an interview, if someone uses the word “architecture”, then I know I’m dealing with someone clueless.

  3. Dealing with an architect at my current job. He doesn’t code. His git “migration” involved 1. ask network team to install Atlassian stash on a server. 2. Copy current code base to that server. 3. git init with that code. 4. send mass email saying “git migration is done”. Later there are bugs and we have no history and we want to go back and see what has been checked in. His response? “Stop wasting time trying to look at history. Just replicate the bug and fix what the problem is” Other than that, in his own words, his duties are: “Observe code and respond by email”. He was once a coder but his code was sooo bad, and he delivered such bad products to the stakeholders that they did not want him to code anymore. So now he’s just a useless appendage that blames others and makes it difficult for others to succeed at doing things.

  4. This architect also blames others for things that are released into production that break things. Then it turns out the people he blames were not responsible (he actually merged two branches incorrectly in git) and HIS manager sends a mass email saying “Let’s try to not blame others”. Other things this useless architect does:
    1. Brings parts of guns to work.
    2. Says he wants to code despite knowing he’s a disaster at doing that.
    3. Refuses to maintain his own code that is buggy and assigns blame/tickets for his own code to others.
    4. Always says “it’s not in my job title.” “I’m not responsible at all for jenkins building and git integration”
    5. Passes the buck for every single thing he finds troublesome.

  5. Wow. This was pretty long winded.let’s face it there are a lot of people in software that don’t know what they’re doing and can cover up their bullshit with documentation and politics.

    I’m a software architect. But you know what, I earned that position and title through 15 years of hard work designing and implementing software solutions. I still write code. I still deploy software and automate processes. What I do that our developers don’t is interface with clients, join sales calls as technical support, and lead our software evolution in a sustainable manner.

    So get off your high horse as a developer. We know you’ve been in the trenches. Software is hard work, get over it. Realize that you own your own career and go work with people who will appreciate you and your skills.

  6. Excellent post. I recently had the same issue of a skilled manipulator that doesn’t know shit about programming just screw the code up. Upper management really doesn’t have a clue but I guess most companies has enough money to pour into the toilet.

    Even worst, my architect’s best friend who is coincidentally the team lead is a stick. He cant learn so needs to sit beside me 100% of the time to watch me code and to ask me questions with answers I give that he will not understand due to his intelligence level then just to tell me off for my lack of communication skills.

    My solution as a developer (provided if you got top skills), look externally for an architect or tech lead position and if you are in control, you can make things right. Or consider moving to a country that is known for software sweat shops.

    For my project, I could had done it in 3 days myself, but took these 3 teams of combined 12 developers 6 months to mess the code base up good. All 3 teams led by the architect demo their pieces and it worked perfectly, but screwed up 40 percent of the existing functionalities that was working before.

    Just want to let you know, that I am in the EXACT same situation you described.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>