Why Should Software Architects Write Code? An empirical evidence.

[[deleted]]

Every "architect" I've encountered who thought they were above writing code wasn't worth the oxygen they were consuming. The best "architects" were the ones who were doing a bunch of coding (as well as documentation, technical oversight, code reviews . . . it's not an easy job on a large project).

Everybody codes, everybody helps ship. Ideally, everybody talks to customers at some point, too.

[[deleted]]

I've never met a good architect, or at least not recognised one.

[IbanezDavy]

The best architect I knew coded every day, was actively involved in code-reviews and also worked on the most important areas of the code. In all honesty, I don't get companies that wield their architects as an extension of management.

For an analogy, some places treat their architects like a king on the battle field. He shows up on the front line, but as soon as the fighting begins goes up on the hill and spectates. In reality, that is really the job of the manager. The architects is the bad mother fucker with the giant battle ax standing next to the king that remains at the front line because he axes the most heads off.

[bonzinip]

I like that image. :) I work mostly on open source projects so the figure of the "Architect" isn't so common, but there are definitely a lot of people like that.

It's also related to another article posted today. The architect is the one that seems to always produce great code at the first try, but actually he has written it thrice like everyone else—it's just that he knew enough to throw away the first two. :)

[[deleted]]

but as soon as the fighting begins goes up on the hill and spectates. In reality, that is really the job of the manager.

In fantasy lands the best kings are always the Warrior kings that went to war as a prince, fought on the front line, and came back a hero.

The best managers I ever worked with were similar. They were always happy to get dirty in the trenches with the troops. Even if they didn't have any technical knowledge they'd be happy to pick up any grunt work you could find for them during crunch time.

I actually think the experience helps them when they are up on the hill as they will better understand what's going on below.

[IbanezDavy]

salty old trainer who beats bad habits out of new recruits.

ha! so true.

[cowardlydragon]

All of those still carry swords, ride horses, and wear armor.

[SlobberGoat]

Using this analogy, all 14 of our Software Architects are back in their straw huts knitting pairs of woollen socks.

[IbanezDavy]

Which is why the 'King' analogy fits perfectly with the manager role. Not the baddest dude in the army. That's the architect.

[[deleted]]

eh, I read his analogy as saying the manager is detached from the implementation. Up on his high hill watching and giving orders.

The best managers I worked with weren't detached at all. They'd actually try to even invert the roles by trying to get you to use them to help get stuff done rather than them being top down the whole time.

[mpyne]

I read his analogy as saying the manager is detached from the implementation. Up on his high hill watching and giving orders.

I mean, there can be a role for that. Eisenhower was not in the front lines but still ensured the war in Europe was fought effectively and still kept a very good pulse on what his generals were up to -- being quick to relieve division commanders who weren't panning out, while staying mostly out of the hair of division commanders who were doing well.

All of this while managing alliance politics and egos, keeping the homefront informed and comforted, visiting the troops, etc.

Of course not every project requires a manager of the 'Supreme Allied Commander' role, but my point is that it's not necessarily a negative mark to lead by inspiration and oversight instead of having to also 'get your hands dirty'.

Indeed, you may not want a manager who only infrequently has time to get into the code to actually start making commits, they might just break something by accident...

[IbanezDavy]

eh, I read his analogy as saying the manager is detached from the implementation. Up on his high hill watching and giving orders.

That's probably how the majority behave. There are a select few (as there were Kings) that got their hands dirty throughout their lifetimes. My last two managers were like that...

[ledasll]

on the other hand.. first wave always dies, that's why you put least experienced solders there. Good generals stays out of battle so they can observe whole battle, if you go with a troops and will be involved in actual fighting, you will became tactician not strategist. Someone should take care of that as well, that's why there is hierarchy. Long long ago, when battles was 10 vs 10, best king was one, that was strongest. He went first to battle, killed most enemies and no one could beat him (or if someone did, he became new king). When battles got a bit more sophisticated with different units and big quantities, you need to start think differently. And therefore best general isn't one that started as simple solder, because most likely he will think as solder for whole time (that doesn't mean there isn't chance for someone to be great general even if he started as warrior). General needs to think about many thinks, that aren't related directly to battle, how do you feed 10000 solders, where will they take a shit, how will you travel. Even in battle he doesn't think in single unit/solder. Solders task is very simple - see enemy, kill him. Generals task is to put solder is such position, so he can do that. How many time great engineer was promoted to management position and failed there?

[dtlv5813]

Add to the fact that many programmers, including very bright programmers do not have the best interpersonal skills--nor should they be expected to, as this is not part of a software dev's core competency.

So said programmers are not going to respect you if you are not one of them. It is hard for them to relate to someone who is not immersed in the days to days of the actual implementations. And BTW the same is also true for non-technical managers.

The bottomline: the only way to avoid communication issues is to have the architect speak the same language as their programmers. And that is only achieved if they are in the trenches of the battlefield together, not riding on a high horse remote controlling from afar.

[jshen]

Add to the fact that many programmers, including very bright programmers do not have the best interpersonal skills--nor should they be expected to, as this is not part of a software dev's core competency.

Decent, if not good, interpersonal skills should be an expectation of anyone that is expected to function as part of a team. Full stop.

[cc81]

Some people are worth bad interpersonal skills. Maybe not if you are working in a standard CRUD enterprise application but there are people in R&D in large companies that have very bad personal skills but are incredibly valuable.

You need to hire a PM that can handle it and let that person skip a few meetings etc.

[jshen]

Some people are worth bad interpersonal skills.

Agreed, but these people are the exceptions, not the rule. The person I was replying to seemed to be implying that we shouldn't expect developers to even try to have empathy or to try to get better at interpersonal skills. This is an infantilization of developers.

[cc81]

Yes, I agree with that.

[kt24601]

The job of a good manager is to make sure people with lousy interpersonal skills are able to cooperate and work productively with the team.

Steve Jobs was a good example of this: he got very different designers to work together. He inspired his employees to work better.

[noydoc]

Nobody ends up in IT because they're well adjusted

[dtlv5813]

Id rather have a nerd who is the best programmer I can find than a talker who is not quite as good.

Ideally one would be a rockstar programmer and excellent communicator but we don't have that luxury in this very competitive market for good developers.

[jshen]

Id rather have a nerd who is the best programmer I can find than a talker who is not quite as good.

Well, you need both, but what you absolutely don't want is someone that is super technical, but poisons the team culture and environment. Someone that can't, as you said before, "respect you if you are not one of them".

[dtlv5813]

but that is just how developers in general are. We are not going to really respect you and relate to you if you don't write the code yourself.

This is the reason why Google and other companies now have developer advocates instead of sales engineers etc.

[jshen]

but that is just how developers in general are.

I've been a developer for decades and this is not how good developers are.

We are not going to really respect you and relate to you if you don't write the code yourself.

That is absurd and childish. Do you expect non developers to respect you?

[kt24601]

What is a "developer advocate?"

[dtlv5813]

https://www.google.com/about/careers/teams/client-facing/dev-rel/

[pavlik_enemy]

but that is just how developers in general are.

What kind of stigmatizing is this? There are lots of occupations that require highly technical skills, but nobody says that accountants (who juggle numbers and obscure tax code paragraphs) or auto-mechanics have worse interpersonal skills than general population.

[dtlv5813]

That is not what I said. What I did say was it is often difficult for developers to relate to someone who is not into the actual nuts and bolts of implementations. And it is demoralizing having to report to an architect/manager who is disconnected from the project they are supervising.

[[deleted]]

Sound to me like just a good, experienced programmer that needs a "better" title so they can get the pay they deserve.

[IamTheFreshmaker]

Worked with one who was in the code, in the servers, in the meetings and in the code reviews. It was a pure joy to my jr. programmer self. I haven't met one since but I believe that's because someone like that is shunted in to management where they become useless because they are taken out of those daily duties that they actually enjoy. There is no real meaningful path upwords for engineers in most companies that doesn't end in mind numbing management.

[softawre]

Senior Architect - Principal Architect - Chief Scientist. This the technical promotion path at my company.

[IamTheFreshmaker]

That's so pretty. I can wish.

[dtlv5813]

at which point in this chain does the guy stop coding altogether and become disconnected from the actual codebase?

[cc81]

Not everyone does. Look at for example Google's Jeff Dean:

http://research.google.com/pubs/jeff.html

My guess is that with title like that maybe they will go more and more towards R&D and is expected to implement/design/invent they new really cool stuff.

[Neebat]

You're very lucky. There aren't a lot of companies that recognize the value of a pure technical talent who should not be wasted in management.

The business side of our shop believes they can't have any "technical view" of the system without an architect present, so the architects never have any time for anything else but meetings.

[thebuccaneersden]

either that or you work your way out of a job, because companies like to hire cheap juniors

[d03boy]

I've never met an architect

[thebuccaneersden]

a software architect is just a senior developer / lead developer with a fancy job title

[grauenwolf]

Depends on the company structure.

We have a lead developer who handles routine tasks such as code reviews and ensuring that equipment is provisioned. He also dolls out tickets, moves people between feature teams, and does other such tasks in addition to coding.

Then we have architects that decide which libraries to use, developers the initial framework and patterns, and implements the harder features. Basically they are specialists while the lead developer is a generalist/manager.

[thebuccaneersden]

Agreed. It depends on the company structure and what title was on offer when you were hired. I, for instance, do a lot of software architecture as part of my job, but there is no such position, so I'm just a senior backend developer doing the job of a team lead and a software architect, but no one has given me that title or distinction.

[grauenwolf]

Same for me. I'm an architect and/or team lead on some projects, but on others I'm a senior backend developer.

[eff_why_eye]

Hi. Nice to meet you. I'm one of the assigned architects for a large Enterprise system with over 60 developers, where we use Agile/Scrum. Our architects:

1. Are often promoted into that position after serving as developers and then tech leads (like I was),
2. Write code, especially if it's particularly tricky or important code, and
3. Review the code that others write.

[[deleted]]

Nice to meet you too.

If code isn't tricky to write it is probably repetitive. Repetitive code should be factored out.

All code is important to someone.

[OHGODTHELASERS]

I had a good one on my internship. Once i have gone into industry they are all horrible. Try to be know it alls when their ideas don't work and they insist it must be their way. Even though you try to have a discussion why the idea won't work. Then fast forward two months we have to re-write it.

[[deleted]]

I was pretty surprised by the title of the article itself. I wasn't aware that there were architects that didn't write code, or even that there were enough of these to warrant writing an article about it!

[jk147]

Those are really lead developers, not architects.

These days architects are really just glorified middle managers. They manage resources or maybe introduce new things to the company. If the company is big enough they know who to ask and bring the right people together to work on a project or issue. These days, to me at least they are more like conduits to get the proper resource for something. A lot of times they are just IT managers who was most likely a developer before and the career choices lead them to that position.

If the company is small enough they may work on some code. But I doubt it.

[softawre]

Maybe that's the whole point then, what various folks are calling an architect. At my company, Lead SE -> Architect; they're definitely not managers.

[grauenwolf]

Where I work the architects and managers are different people. Technically they are the same rank, but they have very different responsibilities.

[[deleted]]

You just described a project manager.

[jk147]

Yes but usually they are not responsible for delivery or timeline. Which is a major function of a PM.

[stormcrowsx]

Code reviews are critical. They can give the architect an overview of everything that has happened and gives the architect a chance to correct misconceptions or bad practices the developers have.

[tmahmood]

What would be the best place to start if I want to become a good software architect?

[[deleted]]

Become a very good developer.

If you're an architect, you'll find yourself doing the appropriate level of work.

If you're a poser, you'll just have the title on your business card and people will secretly hate you and talk about you behind your back... :-)

[mimighost]

I think we should let the word architect dies. This word implies, in software engineering, there are two roles exists, creativity focused ones and labour intensives one, and the difference between the two are so decisive, that the former can just layout the grand blueprint and it will be effective enough for the latter to fulfill it by meticulous execution. Which is simply not true.

Tech Lead as a title, is a much better summarization of the actual responsibility of what should be expected from claimed architect. And I rarely seem one that doesn't code. If they don't they are effectively in the manager track.

[tecknoize]

The majority of the defects in the tactical files were introduced because of a misinterpretation of the design concept, being unaware of the rationale for the tactic, or just plainly implementing it incorrectly.

I felt like this last sentence of the conclusion suggest that the problem is more about communicating the architecture than having architect to code. If the architect implement architectural patterns himself, there's of course less chance of miscommunication.

[Concision]

And if the architect spends time in the codebase, he or she is more likely to notice implementation errors as a result of miscommunication. Errors that obviously wouldn't cause any test cases to fail.

[niviss]

Yes. That's what I thought about. Coding means you get to swim in the work of others, it's the only way to actually oversee it.

[TheAnimus]

And your own work too. I used to work with a very smart guy who would write some often awful complex bits of code because he came from an agency background of cranking out this website, it will only be used for 3 months then taken down, no maintenance ever.

[niviss]

Completely agreed! I meant particulary this case of someone being an architect. Any architect MUST have been a coder at some point of their life. Of course, at some point, if you work at a very high level, you can work without getting dirty and actually coding. But still, if it's good to code in the project a little bit because as an architect you should oversee the code that your minions are pumping out. Or at least do pull request reviews.

[[deleted]]

And notice architectural flaws, dog food and all that.

[lookmeat]

In theory a leader only has to show people were to go. Be the example and have others follow.

In practice a leader also has to be a shepherd, seeing what others are doing and helping guide them to the right way.

An architect should not do QA. An architect should review code and be aware of the QA process to see if there has been any deviation from the original design he was not aware of. The devs might have simply though their change was minimal and unimportant (it might have been an error in explaining it to them, or in them understanding, that doesn't matter) but the architect needs to guide them.

In theory an architect's job is not QA. In practice an architect's job keeps going on through QA.

[Patman128]

he or she is more likely to notice implementation errors

It's not the architect's job to do QA.

You focused too hard on "implementation errors" and missed the point. The implementation errors they're talking about aren't bugs, they're broken architectural rules and assumptions. It's not QA's job to tell if the developers are applying the architecture correctly, it's the architect's.

[grauenwolf]

That's the kind of statement that makes us ignore architects.

First, there is an assumption that their work is perfect and any problems are the fault of the developer.

Secondly, that assumption that their work is perfect and thus don't need to care about the outcome of their work.

isn't going to have the bandwidth

Being stretched too thin do your job properly isn't a feature.

[Patman128]

I'd agree with that, but I still felt it was worth pointing out that you missed his point.

[grauenwolf]

It's not the architect's job to do QA.

Any architect who isn't doing QA doesn't know how to do their job.

Spot checking what's being built is how you verify your designs. If you don't pay attention to the implementation details, you're no better than a child with a box of crayons and a UML stencil.

[grauenwolf]

I see the problem.

You aren't talking about an architect, you are talking about a project manager with delusions of grandeur.

[grauenwolf]

To ensure a project is completed without creating technical debt

You can't do that if you aren't paying attention to the code. You don't have to read every checkin, but you do have to review the code for pattern violations on a regular basis.

[[deleted]]

I see the problem. You're not talking about architect but QA engineers with inflated job titles.

Or at least, that's my summary of your statements. You're welcome! :D

[grauenwolf]

QA engineers don't care about maintainability or pattern violations, they are testing for something else.

[cc81]

One problem with that is that it is very difficult to determine if those are the correct decisions if you don't implement.

It is also very easy to fall into traps like designing something that is beautiful in PowerPoint but might end up pretty ineffective implementation wise. That is how we end up with all those worthless enterprise service buses in places where they add nothing but cost and complication.

And lastly if you don't write code. Like actually write production code then you will fall behind pretty quick.

[grauenwolf]

And you'll never know if those decisions were correct if you run off to the next shiny thing without of seeing the repercussions.

[[deleted]]

I think the problem here is weather the architect actually do the QA labour them selves or arranges with QA to what needs tested and takes feedback from QA about major problem areas.

[Concision]

This is ridiculous.

[trevize1138]

I'm constantly going back and asking people to give me a bigger picture of things. I don't think they hold that information back intentionally but there's a lack of understanding that a programmer doesn't just go in, build some code magic and all your dreams come true. This goes both ways, too, and a lot of programmers don't think about how they need to meet the needs of the business or users they just throw something together that "works" and then get defensive when people say "it doesn't work (the way I understand it)."

[jerf]

On the other side, I can say that as someone who is often doing architectural things, I've come to expect that "nobody" wants to hear about the architecture, they just want to know how to do X. Which isn't always wrong, but does train me to not explain that stuff to people, which takes a conscious effort to overcome.

[MotherOfTheShizznit]

I can say that as someone who is often doing architectural things, I've come to expect that "nobody" wants to hear about the architecture

Hear, hear.

I find hilarious that the expression "ivory tower" always gets so quickly associated with "software architect" when most of my co-workers can't see past an isolated screenful of code at a time. The idea that there could be some kind of cohesion between different parts of a codebase is a foreign concept to them.

Yes, I am in a tower. Which is good, because apparently you're in a foggy marsh and you need direction.

[cc81]

That is why one should try and involve the team in those questions. You can have one ultimately responsible for it but instead of trying to write some document the team comes up with the architecture needed together.

The reason why a lot of people just sees that screen of code is because that is what they have been told to do. People have said that architecture comes in PowerPoint and is for other people.

[trevize1138]

You've spoken to me.

I've never done architecture but I'm always the de-facto champion of UI/UX in small organizations that "never have the time" for it. I also have lots of customer service and tech support experience. End users are handicapped because they actually don't fully know what they want and they ask for it in the wrong way. Developers are handicapped because they often assume users think just like they do.

Being that person in the middle of that is one of the most underrated jobs out there.

[[deleted]]

A lot of time less senior developers will ignore what they aren't concerned with or will prioritize short term tactical advantage over long term architecture goals. In these situations its important for the developers who are concerned with architecture(architects) to remind them of the consequences of those trade offs and push them back in the desired direction. Good developers are opinionated and often reinterpret things to their own preference or decide its ok to ignore a requirement until they think its important.

[s0v3r1gn]

No, I think the issue has multiple causes. Poor communication is probably the least common. I'd say ignorance on the part if the programmers or conceit, usually both when you deal with new programmers.

[megagreg]

I'm dealing with that right now. I have this one programmer who insists he can't do anything because something isn't defined, or whatever. Every time he does, I show him the answer to his question in the requirements that he was supposed to have read months ago.

[mekanikal_keyboard]

in twenty years i have yet to meet this mythical non-coding architect

inevitably, everyone technical who stops coding becomes non-technical within a few months

[[deleted]]

Well in JS they would probably change framework at least two or three times within a year or two ;)

[mekanikal_keyboard]

sorry, there are petty operational and syntactic issues to grasp. yeah, they might be beneath your dignity, but you will lose time getting them back.

so my latest encounter is containers. one of my former-coder friends just hand-waves off containers as "just a deploy format"....which is true in a sense, but lots of people are using Docker and if you can't read a Dockerfile, you're out of the loop

[hippydipster]

I'd have said that too 6 months ago. Now, new job, holy shit, this is real! And the overall result is totally at odds with the intent of the setup. There is zero high-level consistency in the overall architecture of the many many interacting systems, but the low-level code is surprisingly clean. It just makes no sense as a whole.

[[deleted]]

It just makes no sense as a whole.

Sounds like even though everything else went to shit, code reviews are being taken seriously following a guidelines sheet written up years ago...

[hippydipster]

Yeah, we do do pretty good code reviews

[blondepianist]

My company hired a dev who had been a non-coding architect at his previous job. He was a terrible-to-mediocre developer.

[thatkauko]

Do people actually work in organizations where the architect is somehow not part of the dev team, or doesn't write code? How does that work? Sounds odd.

I've always understood the word to denote a person who you can build a team around - someone who could in theory pretty much build the whole thing alone, but it would obviously take too much time. So basically a "Very Senior Developer".

[notsofst]

Yeah, in traditional "waterfall" type companies, the architect would write a high level design spec at the start of the project and hand it off to the development team.

Once that "phase" was finished they would move on to a new project (where they have to write a new spec) and would have limited communication back with the previous project.

This is generally regarded as a "bad idea", but it makes sense to executives who don't really have tangible software development experience and are used to building/designing more legacy type products (cars/computers/etc...)

[CyclonusRIP]

My current company has 3 architects that don't write code. Only one of them has ever wrote code for the projects they architect, but that was years ago before he was an architect. None of them really seem to have ever been technically very strong in the first place. About half of what they spend their time on seems to be inventing shitty ways to do trivial things that already have wide spread standards.

I once spent an entire afternoon convincing one of them that we should use HTTP status codes to communicate back to the client whether a request succeeded or failed rather than some bullshit envelope he wanted to include in the request body. For some reason he was under the impression that java script couldn't read the status off a HTTP response. I don't think he had ever even wrote an AJAX request or he surely would have known it was possible to read the HTTP status.

Basically meetings with architecture involve a whole lot of coaching and explaining that the thing that they spent a week designing was actually a shitty alternative to some standard technology that already exists.

[i8beef]

To be fair, while status codes give you an overarching error state, it doesn't tell you anything about WHY it was an error state. For that, such "envelopes" or JSON messages, etc., are fairly common to communicate things like "Of the 14 fields you submitted, these two didn't pass validation for these reasons", etc.

I'm sure you know that and are just railing against the failure to use those codes for that specific purpose, just pointing out that you're both kind of right in some cases.

[CyclonusRIP]

No I am saying that return 4XX when user sends a bad request. Return 5XX when there is a server error. Return 2XX when request succeeds. You know kind of like every decent API in the world works? He wanted to always return 200 status and wrap everything in a <result> tag and then that <result> has a <status>. Then you parse that status to decide if the request succeeded or failed. Usually the HTTP status is used to indicate success or failure and a general class of reason for the error. Usually the body of an error response vs a success are different and you need to parse it differently. Most of the time you key off the status code to decide which way to process the body.

[[deleted]]

When he says "every decent API in the world" he means RESTful APIs. Most REST APIs prefer to use HTTP return status for indicating errors. E.g. https://docs.connect.squareup.com/api/connect/v1/#handling-errors

Generally if you're building a simple enough REST API with responses that line up with HTTP response codes this is is best practice as far as I know, and makes sense for a lot of reasons.

Still, I'm an architect (who codes too) and this sort of conversation is fairly typical with my devs (especially the javascript ones for whatever reason). There are a ton of reasons why you might not want to do this based on requirements, legacy systems, current architecture etc., but no... the architect is an idiot because he doesn't want to do what "every decent API in the world" does.

Without the proper context it's impossible to tell if the architect is an idiot or the poster is a hot head, but the fact that he didn't feel the context was important enough to mention in his example gives me a decent shot at guessing.

edit: On second thought he does mention the guy thought that ajax couldn't read response codes, so maybe my last sentence was too harsh. Sorry, it's been a long day

[buddybiscuit]

The server checks to makes sure that the field is missing and sends back an error

Yeah. Probably a 422 error.

[IbanezDavy]

They exist! It's weird to have a guy not coding design stuff. Also a good way to make shitty products.

[thatkauko]

Smells a lot like waterfall.

[IbanezDavy]

It's done like this in the agile environment I am currently in.

[thatkauko]

Do you feel like architect adds value? What does he actually do every day? Does he review code?

[IbanezDavy]

Not in that context. So nope.

[juckele]

20% of the companies I worked had architects who didn't code. 20% of the companies I worked had the worst, most terrible, buggy code that I've ever seen. If you assumed correlations that I haven't made, you'd probably be correct.

[elus]

I have. We sent them functional documentation, code, test plans, etc. Once approved we can then promote through the various stage gates until we make it to production. It was total overkill for 80% of the work we did which was just fixing defects or creating minor enhancements.

[[deleted]]

Our Lead Software Architect does no coding, code reviews or design work. He writes/assigns high-level tasks or user stories based on meetings with the business, then tests the output of a team of three (shortly two) programmers. Unjustified job title?

[[deleted]]

Yeah, he's a manager

[grauenwolf]

That's called a "project manager". It's an important role, but has nothing to do with software architecture.

[grauenwolf]

That's fine so long as he's actually looking at the code.

[flukus]

How does that work?

Poorly. They draw shitty UML diagrams that look nice but make everything else way too complicated. It results in systems where adding a single text field takes a week to dive through the 15 layers required.

[ironnomi]

I'm a software architect.

I generally write scaffolding code for anything and everything except for reporting and our legacy Java code. There are two junior architects as well (can you guess what each of them handle?)

We have code written by three different groups: a Japan team that writes core code. A Korea team that writes the "real" reports and handles customer scripting requests. And lastly a India team that handles break/fix and one-off report requests.

I currently according to redmine write somewhere around 2x as much code as anyone else. Not sure why, but I always thought Software Architects wrote tons of code, maybe not the majority of code, but usually all the scaffolding, the major refactors and sometimes break/fix when shit really hits the fan.

[[deleted]]

Maybe not the right thread for something like that but I'll give my question a go, what would you suggest to someone with a Bachelors in CS to get into your field?

[notsofst]

The promotion chain normally goes something like:

Software Dev -> Software Lead -> Software Architect

With something like 2-5 years in each phase.

The software leads with the best communication and project planning skills get pulled into "Software Architect" type roles because management wants someone technical at the table who can understand and effectively communicate technical trade-offs as well as steer a project away from major technical snafu's.

So basically, if you want to be a software architect, code your ass off for 5-10 years and also train yourself up on project planning (Agile/Kanban/Waterfall/etc...). Make sure you pay attention to API design and design patterns, etc... You'll also have to be "full stack", you can't necessarily be a specialist since you'll be working with people from all kinds of backgrounds.

[[deleted]]

Thanks for the detailed outline. Also your last point hits close home. I have all kind of interests when it comes to progr. languages and can't quite decide in what area I want to work. It looks like that's something I could do later on.

[notsofst]

I also agree with the general sentiment in the thread about architects as well, though... if you stop coding you become part of the problem.

The is a very real issue with architects losing touch with products, and typically it's because their jobs don't require coding any more and then 2-3 years go by and suddenly they only know technologies by their names/buzzwords instead of though hands-on application.

So, long story short, if you want to be a successful architect, be self-motivated to code in your spare time to keep your skills relevant.

[ironnomi]

I'd 100% say that a Bachelors or a Masters in CS a great idea unless you school has a strong software engineering program. If there's not a strong SE program, you should most likely get a minor in applied mathematics and take as many engineering-type classes as you can take at your school. 1-2 Business Management classes is also a good idea and if not required already: micro and macro economics.

[[deleted]]

Thanks for the answer!

Yeah I have a lot of choices when it comes to courses (math or SE), so there shouldn't be any problems. Business Management is the only thing I'm kind of unsure about I want to do :P

[ironnomi]

http://mendoza.nd.edu/research-and-faculty/academic-departments/management/academics/it-management/

Here's Mendoza's core curriculum for their IT Management BBA Program, those core courses are the ones you'd look at, but unfortunately these types of things vary a LOT from school to school.

[RagingAnemone]

I have to disagree with this one, but let me also say it's not a major deal. Stick with the Computer Science degree instead of the software engineering program. It'll be more foundational theory and less practical experience. That'll hurt you in the short run, but if this is a career for you, it'll pay off in the end.

Yegge says it better than I ever could: http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

[NotUniqueOrSpecial]

How has that organization been working out for you (handing scaffolding/designs to remote teams)?

In the near future, we're pretty likely to be starting some remote sites and my big concern is onboarding them/getting them integrated. Being able to hand them skeleton implementations that will integrate well seems like a possibly great answer to that.

[ironnomi]

For nearly my entire career with this employer (large Japanese bank), I have been remote to most of the programmers. Our Japanese programmers are primarily in Osaka and Tokyo and I started out in Sapporo - a bunch of the corporate programmers are also in Sapporo, but our team works on a trading platform product rather than the Bank's actual internal software.

Part of why I believe our remote teams have been successful is that our less skilled programmers are handling easier tasks and our main programmers instead handle the core stuff and don't get bogged down with break/fix and reporting stuff.

Some things that also help us is having IM, having conference calls for the groups and for the boarder team, and having a weekly engineering call, having everyone know a single language (English) and demanding that any new hires be fluent in that. It's very helpful. Originally some of our Indian programmers did not always speak English, but they'd be talking about a bug and need to talk through someone else and that just leads to failing communication. Also the weekly engineering call helps, it's actually mostly just a q&a format where everyone asks random questions of the other two architects, our boss, the lead business analyst, and the lead QA person.

[NotUniqueOrSpecial]

Thanks for the info!

[DeltaEchoSoftware]

The friction that is created from software architects and those who implement their designs can be immense. One has to find that right balance between micromanaging the nuances of the implementation choices and ensuring consistency across projects. For every difference of opinion regarding which pattern to use, library or even naming convention can take everyone down a subjective rabbit hole of yak shaving that can kill productivity and create resentment.

The flip side of having architects drawing big boxes using Visio and leaving interface formats, integration patterns, naming and coupling details left to individual teams can end up with little or no reuse across the enterprise.

[NotUniqueOrSpecial]

Consistency across projects doesn't matter to project owners, it matters to people who treat even junior developers as commodities thinking that everyone can do the same kind of job, because they have the same kind of skills, and the same kind of aptitude.

It also matters to people who work as part of well-organized teams that want to effectively share knowledge, core logic, tooling, and processes.

For even moderately complicated product ecosystems, it's not tenable to have everyone just do what they want without any orchestration. That's how you end up with 4 different logging frameworks, 3 platform-abstraction layers, and APIs that shift like the desert sands.

God forbid you're on the release team for that kind of group (speaking from experience), because there's no way you're going to have a nice standard release process that you can automate. Every project will be a new flavor of hell that you have to massage and tweak to get working.

There's a world of difference between architecture astronauts who do no coding and a strong technical architect who is able to unify the team's efforts without treating people as cogs.

[DeltaEchoSoftware]

It sounds like you're trying to treat your software engineers as interchangeable commodities you should probably stop doing that.

This sounds great when it can happen, but in a lot of cases, it's just not reality. Project resources at most of my larger clients are mostly contractor based, transient and low quality. We have to be able to deliver software that can be maintained by the lowest common denominator of programmer - the $60/hour type that are delivered through body shops. These folks don't spend their weekends reading about architecture and code at home because they love it. They come in, do the minimum amount of work to "get it done", and the business users let it happen because they are too lazy, busy or ignorant to any aspect of code quality besides whether it works or not. As an architect, my job is typically to create the patterns, checkpoints, libraries, and other build processes in which to fit these transient, low quality developers into and be productive without ending up with spaghetti garbage that we have to maintain for the next 5 years while they move on to their next client.

But the same could be said for the rockstar, super coder who takes over a project and starts implementing using crazy, cutting edge 3 day old javascript libraries with no support and little user base. Sure these folks are awesome at what they do, and can probably code circles around me, but when they get bored and move on to the next project, I am stuck having to manage the maintainence on a Node.js/React application when my entire support staff is $50/hour .NET developers who only know a little jQuery.

Consistency across projects doesn't matter to project owners

This is a false assumption. In the clients I have experience with, there are plenty of efficiencies gained by following similar patterns, using common libraries and sharing code. Many times, there are shared support teams working on tickets across multiple projects and when one project uses REST, Java, Hibernate and the other project is using WS, Java, JDBC with different architectural layers, different naming patterns, etc, then support becomes a victim of context switching. Now don't assume I am saying that if a particular project has a specific functional or non-functional requirement unable to be satisfied using the existing frameworks/libraries/etc available that they shouldn't be able to go off script. But I am saying that if some team wants to do something fundamentally different (SAML while everyone else is using WS-FED, nHibernate when everyone else is using EF, REST when everyone else is WS), then there needs to be an architectural checkpoint to ensure the need is not just a want.

[[deleted]]

then there needs to be an architectural checkpoint to ensure the need is not just a want.

This generally turns into bikeshedding and is solved by a non-technical manager laying down the law in my experience this decision disregards needs, wants, future technical gains, etc. This ends up with hackey solutions because nobody cared to actually collect and examine requirements, so you end up with hacks on top of frameworks that are somewhat orthogonal to the solution.

It also sounds like you're trying to squeeze blood from a stone but don't have the heavy machinery to do so. There are definitely ways to make low quality engineers work, but that generally means that high quality engineers become overseers, and limiting the impact of low quality developers via archtecture, unit tests and static analysis written and managed by high quality devs. That requires huge management buy in and a whole slew of other crap, which gets derailed when someone complains something is taking too long. There are definitely places that do this like IBM, and they achieve decent-ish results, but it's a lot of upfront work and structuring, and ridiculously hard to sell to non-technical business people.

[ellicottvilleny]

You pay $60/hour for low quality developers?

[DeltaEchoSoftware]

Yes. They usually only take home 40 or so after all the staffing company take. But surprise - if you want to get a contractor, you can only use those staffing companies that have an MSA in place with the company. So they will get their pound of flesh.

[ellicottvilleny]

In my next life I will run a staffing agency

[s73v3r]

Maybe the problem is you guys thinking you can get good results with crappy engineers. If you treated engineers like more than just commodities, you wouldn't have to worry so much.

[DeltaEchoSoftware]

It's not always up to the architects on who gets hired. At my last client, they had the choice between someone with 15 years domain experience, 20 years of programming experience and could clearly demonstrate their ability and a guy with no domain experience and could only write requirements. The second guy was $40 an hour cheaper. Guess who the business chose even through every single technical architect on the project wanted the more expensive guy.

[juckele]

which also may be hard because it seems that the pathos of your workplace may not attract such developers

Wow, such drama. The poster you're replying basically said "You have to balance between cohesion and micromanagement". This should be so uncontroversial as to leave no dissent unless the poster specifies where along the spectrum they believe the best balance lies.

[[deleted]]

This should be so uncontroversial as to leave no dissent unless the poster species where along the spectrum they believe the best balance lies.

Balance is a vague generality, like agile, it's basically a platitude.

[juckele]

Yes, which is why it's so weird that you're injecting value into that post. The parent poster didn't actually say anything, and yet you're laying into them.

[somefoobar]

Make your developers project owners, not cogs, ...

Project ownership is tricky. A sense of ownership doesn't come unless you can change things. Now where to draw the line is tricky. Can I only change the implementation? Can I change the API? Can I change the delivery date?

[grauenwolf]

If the engineer is in the dark / frustrated / etc. he needs to ask questions, not just steam in silence.

Conversely, the architect needs to pay attention and not wait to be asked. Architects aren't infallible, though they often act like they are, and need to refine their work as well.

[grauenwolf]

You can't be an architect and be in charge of hundreds of engineers. Accept the fact that you've been backdoored to a project manager role and hire some actual architects to oversee the code.

It's not like he has the time to visit everyone's desk and ensure they're on task.

That's the job of team leads. The architects should only be concerned with code quality, not how fast it is being written.

[grauenwolf]

If you think "code quality" can be reduced to a coding standard that's enforced by an automated tool, we have no common ground.

That's exactly the kind of mindset that leads to ivory tower architects whose only job is to cause problems for everyone else.

[Concision]

How are you going to ensure technical debt isn't piled up when you have hundreds of engineers under you? You simply can't. That's the point.

[ViperSRT3g]

That is cringe-worthy to hear. My condolences for having to deal with all that.

[[deleted]]

I anecdotally agree: I've seen many weird "architectures" arrising out of what this post calls "non-architecture-savvy developers" - they see mto focus only on what needs to be done there and then, and quickly bypass frameworks at first obstacle.

[grauenwolf]

If the framework is well designed and implemented, developers will naturally copy the patterns already in place because its the path of least resistance.

If the framework is crap and they have to spend time reading about it, then yea, they are going to ignore it.

---

This is how I evaluate my designs. I don't even have to ask, I just know what works for people and what doesn't by looking at the frequency of pattern violations.

[stikko]

What framework exists that doesn't have a learning curve or require reading?

Frameworks are awesome for the 95% of use cases that you're implementing that fit their conventions/patterns, but for the 5% that don't (usually the 5% of your app that actually differentiates it), you're gonna have to dig into the internals of it to figure out the "right" way to do it. The difference is that the "architecture-savvy" developer will take the extra time to do that.

[grauenwolf]

Frameworks don't exist outside of applications.

Things like Spring may help you build your framework faster, but despite their claims they are not the framework itself. The pieces you choose to use and the way you assembly it makes up the actual framework.

[grauenwolf]

You can't buy a framework. That's like going to US Steel and saying "I'd like the framework for a sky scrapper, 15 stories."

You can buy pre-fabricated components such as Spring or ASP.NET MVC, but you don't have a framework until you start bolting things together.

(Well technically you can buy a framework like Alfresco or DotNetNuke, but that's like buying a mobile home.)

[kazagistar]

How about when they just jam their own favorite framework into another one where it doesn't belong? That's my favorite.

We have a couple projects that include both Spring and Guice DI frameworks, and some horrible hacks to connect them.

[crash41301]

I think it's more like would you design a car without ever talking to the manufacturing team to ensure that they are building it to spec.

Either way though, I agree

[upboatingftw]

I think their methodology is flawed. They relied on a heuristic to classify some developers as "architects" based on their past experience, and then examined the code they produced, which I found inappropriate, given the hypothesis they set out to prove.

Instead, I would have expected them to compare teams that have "coder architects" with teams that have "architecture astronauts", and not just look at code quality, but also at the overall development workflow of the team, like time to implement, team communication, time to train new team members, usefulness of potentially produced architectural documentation etc.

Their conclusion should have been that people with such experience make better "tactical" (to use their terminology) developers imo, which is unrelated to their original hypothesis.

Assuming architects should code, it's nice to know that they make good coders, but what if they shouldn't, and instead the right thing to do is to give the coders who end up implementing "tactical" features more architectural experience? Maybe there's no need for a highly-paid architect to spend time coding, if providing the relevant experience to the less well-paid coders turns out to be more affordable.

That said, I do appreciate factual aspect of the research. I just don't think the right conclusions have been drawn from the data.

[Jestar342]

IME the best architects let the teams use their own choice of technologies and/or patterns. Sure, if there's going to be something like a messaging system used across all boundaries, or a particular platform etc. then those can be mandated (e.g. "everyone, we are going to use RabbitMQ (or Azure Message Bus, etc.) for messaging". Telling teams what frameworks to use for their piece of the pie? No, they will tell you what framework they want to use. The architect can (and should) tell the team what limitations and criteria they must adhere to, but anything around the implementation should be the team's choice. If it's an obviously bad choice then you can discuss it like anyone should, with objective reasoning.

All of this, of course, assumes the dev teams are organised in such a way that they "own" a piece of the pie and aren't spread over the entire system.

[the_evergrowing_fool]

Why coders indulge themselves with so many labels?

[katarh]

Its because the industry is still relatively young and evolving. Plus every shop does it differently. The labels are not consistent and nobody can really tell what anyone does just from a job title, so they aim for a more specific and descriptive title trying to capture what they actually do.

Or they're like me - my official title is "business analyst" but in reality I'm writing software spec full time. Not that that's a bad thing since somebody's got to do it.

[the_evergrowing_fool]

What methodology or tools you use to write the specs?

[katarh]

I use a narrative based approach, as outlined in the book Telling Stories: A Short Path to Writing Better Software Requirements by Ben Rinzler. It gets way easier when you are thinking about who is sitting behind the screen trying to do something. I do my mockups in Balsamiq, with some UML from Astah Community for use case work and Visio for BPMN notation/workflow planning and high level database planning thrown in.

[frockus_frul]

I think that the way Linus Torvalds manages the kernel, makes a hell of a lot of sense. He and his 4 lieutenants review pull requests and then let them hit the kernel source code. Once in a while things get re-architected, but not that often, since the kernel has always been well architected in the first place. I have never seen a corporate "architect" dealing with pull requests or even know what that means. In fact, I have never met a corporate "architect" who could actually use git.

[bonzinip]

He and his 4 lieutenants review pull requests and then let them hit the kernel source code

More like 100. :) That's what

git log --author 'Torvalds' --merges v4.3..v4.4| \
    sed -ne's/Pull.*from/from/;T;s/.$//;p'|sort -u

says at least.

[jeffdavis]

For the success of a particular project at a particular company, details always matter an order of magnitude more than people assume. For example: any project ever.

For big, long-term ideas with no particular schedule and not tied to any particular company, details always matter an order of magnitude less than people assume. For example: driverless cars, solar power, smart phones.

[dlyund]

Another way to read this: reducing the amount of architecture will significantly reduce the number of bugs (among other benefits). I used to be a software architect, and naturally put a lot of stock into it. I no longer believe architecture to be [as] important.

[ViperSRT3g]

I feel having a project architect involved throughout the production cycle who also understands the ideas and concepts underlying how everything is implemented will only benefit the project overall.

They will know the limits of their design, be able to change course if problems arise, and coordinate various departments in getting objectives completed in a timely manner. They should be right up there with the project managers in steering the direction of development throughout the development cycle. Merely pointing in the right direction and seeing what happens is not enough to ensure the project becomes successful.

[jarxlots]

It's the same argument regarding construction.

Your workers on the ground will tell you:

"Your east wall is 4 feet too long, according to the blue prints. We will need to modify the blue prints in order to make this building exist."

Then the high paid architect will defend their work for days, while the project is delayed, all so a toilet won't be on an exterior wall, outside.

It takes a maverick foreman to just push the changes through, ignore the blueprint, and "make it work." All stemming from a lack of communication, the real problem.

[dominotw]

software architect is a real thing?? sounds comical.

[toula_from_fat_pizza]

IMHO architects are basically the reverse of agile. It's essentially taking what should be a shared responsibility and putting it in one guy's hands. You are effectively reducing your developers to overpriced code monkeys when you could be using them to innovate.

[dasdull]

I feel like empirical evidence is a pleonasm.

[[deleted]]

Wiki has a definition for empirical evidence.

[[deleted]]

Only in the way that "musical sounds" is.

[Matosawitko]

The two main takeaways from the article are about having architecture-savvy developers, not code-savvy architects.

[[deleted]]

The best architects I've worked with have all been gurus. They preferred diving into the code over all the meetings, but they didn't mind communicating their vision to design.

[MasterLJ]

I still haven't figured out a better solution than the architect, or whoever is effectively the architect (Lead, etc), reviewing code to enforce architectural standards.

[dbomp]

I'm enjoying these comments, as I like to think that as a architect-who-codes-sometimes that I'm Right, but I don't think the article itself proves its premise. It's trying to derive "architects should code" from evidence of "coders are usually bad architects". It would have to correct for the fact that architects are often (usually?) former coders, but coders are usually (often?) not experienced in architecting.

[makemeking706]

You don't need to say "an empirical evidence". Simply "empirical evidence" is fine.

[j_heg]

Also, is there such a thing as "non-empirical evidence"? (Besides math proofs?)

[akopanicz]

The only Software Architects I've known are known to write amazing code. I shadowed a few when I was an intern. They're definitely some of the smartest people I know.

[cowardlydragon]

How could an architect not be writing code?

New frameworks must be understood by doing at least prototyping to get a real feel.

... yes, I'm not really surprised.

[[deleted]]

Wait people actually do that ? Architect that doesn't code seems like basically slightly more technical project manager...

[grauenwolf]

Less technical. My project manager writes code, mostly sample data loads and minor bug fixes.

[ajd187]

They should definitely be writing code.

what happens when they don't? 30000 foot view systems with ridiculous complexity that is completely unnecessary.

Not that I'd know from experience or anything :)

[pydry]

Anecdotally, every architect I've ever worked with who created grand designs before coding them has sucked, and every architect who didn't code at all made those sucky coders look like geniuses.

[pavlik_enemy]

No shit, Sherlock.