4 ms·

Software Architects Need More Respect: Hacker Culture Is Overdone

16 points by bernardlunn 15y ago

Some people would say that I am not qualified to write about software development as I have never written a line of code in my life. But I have spent over 30 years working with some great developers on a wide range of projects and I have seen what works and what does not work. A few years ago the art of architecting systems for scalability and extensibility started to get a bad press. I think Joel Spolsky was the first to coin the phrase “architecture astronauts“, to describe those who were always designing layers of abstraction but forgetting to deliver code that actually did anything. Then we got the lean start up movement, focusing on the constant iteration that the web enables. This led to the hacker culture, oriented to “just do it” speed. “Hacker” used to be a term of abuse, but like “punk” it was adopted by those accused as a badge of pride. That is all good stuff, but methinks it has gone too far. We now see too many systems where the original system has to be totally thrown away. That may be OK if you raised $ gazillions and can now compete with Google and Facebook for a big team of really great engineers. But for most startups, it is not possible. So most startups limp along with the original system. The upshot is: Hosting bills that really start to bite into cash flow. Systems that crash too often; a few of these and your users have clicked away to a rival. Yes, we persevered through Twitter fail whales, but is your service really that addictive? New features take way too long. You either release fast or put in some QA and testing process to avoid brand-killing crashes. It does not need to be like that. The best developers can do both. They create a scalable and extensible architecture AND deliver quick feature iterations. Sometimes you cannot get one person who can do both – it is rare. One team I worked with solved this by having a 4 person team where: 1 person hacked demos, in the full knowledge that the code would thrown away. He was awesome at this and in full synch with his colleague who: created the architecture AND the working code. 35 years later, the system is still being used. 2 people who did the ancilliary stuff like testing, documentation and so on. Great surgeons have a team, same is true with great engineers. I think the problem may be with the pure architect model. No engineer likes being told “here is a perfect architecture, just code it as per that spec”. Going back to the house analogy, we need more architectural engineers who create designs that they know will work and they prove that they work by writing the code.

dpritchett 15y ago
It seems the title doesn't quite match the content and thus I was skeptical until the end: "I think the problem may be with the pure architect model. No engineer likes being told “here is a perfect architecture, just code it as per that spec”." This is exactly the problem with waterfall management in general. Some elite management/architecture cabal presents a long-range plan and if things don't work out it's the fault of the grunts for not "sticking to the plan". This type of software development management is quite obviously wishful thinking and intellectual laziness. It puts a dramatic chilling effect on developer creativity and engagement.
- dkarl 15y ago
  I don't think it has anything to do with waterfall versus agile. I work in an agile process as a software architect, and "Here's the spec, implement it" is exactly what I get pressured to do by product owners, scrum masters, and yes, sometimes even by developers, who naturally feel insulted by the idea of having an architect "over" them and have no desire to collaborate on design. The biggest problem with the idea of software architecture is that it's turned into a job title. It stunts both architects and developers by attempting to divide the labor of programming. We are all programmers, and programming is really just design, from the lowest level of designing lines of code up to the highest level of designing distributed systems. Software architects who don't write code get stale very quickly. The longer-tenured architects at the company I work for are sad sacks. I've been on calls where they "reviewed" and approved "designs" that were actually questionnaires filled in by my product owner and fact-checked by me. The documents they read, while accurate, did not allow them to understand the work on any level at all. Their job was to check for things such as, what browsers will this be tested against? You get on a conference call with them, they ask some bizarre questions based on misconceptions they got from inaccurately reading between the very widely spaced lines, they don't understand the answers, and then they rubber-stamp the paperwork. That's apparently a significant part of their job. Meanwhile, the developers are encouraged to remain code monkeys because that division of labor makes sense to management. To the developers, this seems like disrespect, and it is, though it isn't as insulting as they think, because management doesn't realize that they're basically saying that developers sucks at half their job. I don't think "architect" should be a title. Everyone should have the same basic title. Call it "developer" or whatever. Just make it clear that we're all doing the same kind of work. Gradations are okay: junior, senior, longbeard, whatever. There are a million differentiations between different programmers in practice. Senior developers should help junior developers when they need it. Developers should consult with other developers on any difficult or momentous decisions. Some people should be focused on the big picture, but not everyone at the same time. At any moment, some developers will be working on prototypes and new projects, and other developers will be working on maintenance. People will develop expertise and ownership. The point is that every difference is personal. One developer may write stellar systems-level code but have unfortunate taste when it comes to designing distributed systems that work together over a network. One developer may be slow at finishing new projects but good at ferreting out bugs. That's why you need have technical managers with power who make situation-specific judgments about who does what. And that's what this is all about: replacing personal judgment with rules and formulas. Who should design and implement System X, Doug or Sam? Doug, Sam, and their boss know their capabilities. Doug would like to design and implement System X, but their boss knows that is a stretch for Doug and is too risky for the given time frame. Sam knows she can design and implement System X, and so does her boss. So Sam should design and implement the system. Horrible! Unacceptable! Unscientific! Everyone should be assigned tasks based on their job title. Since Sam seems more capable than Doug in this situation, let's give her the title "Software Architect." She will design System X. Since Doug seems less capable in this situation, let's give him the title "Developer." He will implement System X. What happens next release when there's a system that Doug really ought to design, to stretch his design skills or because it's in an area he knows well? Well, you can promote him, and then he'll be theoretically "assignable" to design any project. If you don't want to promote him, then Sam will do the design and he'll be stuck implementing it. Sam, of course, will be kept busy with design work and "supporting" Doug, so she won't code much, and pretty soon she'll be useless and will spend her time in meetings "representing" engineering, telling sales what's possible and what isn't and hoping that her answers aren't invalidated by things that have changed behind her back. Doug, of course, is busy changing things behind her back, because he only gets to make design-impacting decisions if he doesn't admit that they are design-impacting. Wow, this is really a subject that gets me worked up. So much for my productivity this morning. I'm an architect, and God help me, I do not want to have this title at the next company I go to.

16 points by bernardlunn 15y ago

dpritchett 15y ago

It seems the title doesn't quite match the content and thus I was skeptical until the end: "I think the problem may be with the pure architect model. No engineer likes being told “here is a perfect architecture, just code it as per that spec”." This is exactly the problem with waterfall management in general. Some elite management/architecture cabal presents a long-range plan and if things don't work out it's the fault of the grunts for not "sticking to the plan". This type of software development management is quite obviously wishful thinking and intellectual laziness. It puts a dramatic chilling effect on developer creativity and engagement.

dkarl 15y ago
I don't think it has anything to do with waterfall versus agile. I work in an agile process as a software architect, and "Here's the spec, implement it" is exactly what I get pressured to do by product owners, scrum masters, and yes, sometimes even by developers, who naturally feel insulted by the idea of having an architect "over" them and have no desire to collaborate on design. The biggest problem with the idea of software architecture is that it's turned into a job title. It stunts both architects and developers by attempting to divide the labor of programming. We are all programmers, and programming is really just design, from the lowest level of designing lines of code up to the highest level of designing distributed systems. Software architects who don't write code get stale very quickly. The longer-tenured architects at the company I work for are sad sacks. I've been on calls where they "reviewed" and approved "designs" that were actually questionnaires filled in by my product owner and fact-checked by me. The documents they read, while accurate, did not allow them to understand the work on any level at all. Their job was to check for things such as, what browsers will this be tested against? You get on a conference call with them, they ask some bizarre questions based on misconceptions they got from inaccurately reading between the very widely spaced lines, they don't understand the answers, and then they rubber-stamp the paperwork. That's apparently a significant part of their job. Meanwhile, the developers are encouraged to remain code monkeys because that division of labor makes sense to management. To the developers, this seems like disrespect, and it is, though it isn't as insulting as they think, because management doesn't realize that they're basically saying that developers sucks at half their job. I don't think "architect" should be a title. Everyone should have the same basic title. Call it "developer" or whatever. Just make it clear that we're all doing the same kind of work. Gradations are okay: junior, senior, longbeard, whatever. There are a million differentiations between different programmers in practice. Senior developers should help junior developers when they need it. Developers should consult with other developers on any difficult or momentous decisions. Some people should be focused on the big picture, but not everyone at the same time. At any moment, some developers will be working on prototypes and new projects, and other developers will be working on maintenance. People will develop expertise and ownership. The point is that every difference is personal. One developer may write stellar systems-level code but have unfortunate taste when it comes to designing distributed systems that work together over a network. One developer may be slow at finishing new projects but good at ferreting out bugs. That's why you need have technical managers with power who make situation-specific judgments about who does what. And that's what this is all about: replacing personal judgment with rules and formulas. Who should design and implement System X, Doug or Sam? Doug, Sam, and their boss know their capabilities. Doug would like to design and implement System X, but their boss knows that is a stretch for Doug and is too risky for the given time frame. Sam knows she can design and implement System X, and so does her boss. So Sam should design and implement the system. Horrible! Unacceptable! Unscientific! Everyone should be assigned tasks based on their job title. Since Sam seems more capable than Doug in this situation, let's give her the title "Software Architect." She will design System X. Since Doug seems less capable in this situation, let's give him the title "Developer." He will implement System X. What happens next release when there's a system that Doug really ought to design, to stretch his design skills or because it's in an area he knows well? Well, you can promote him, and then he'll be theoretically "assignable" to design any project. If you don't want to promote him, then Sam will do the design and he'll be stuck implementing it. Sam, of course, will be kept busy with design work and "supporting" Doug, so she won't code much, and pretty soon she'll be useless and will spend her time in meetings "representing" engineering, telling sales what's possible and what isn't and hoping that her answers aren't invalidated by things that have changed behind her back. Doug, of course, is busy changing things behind her back, because he only gets to make design-impacting decisions if he doesn't admit that they are design-impacting. Wow, this is really a subject that gets me worked up. So much for my productivity this morning. I'm an architect, and God help me, I do not want to have this title at the next company I go to.