3 ms·

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 enginee

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.
- dpritchett 15y ago
  I think you're describing what Steve Yegge called "good agile" [1]. Each task is handled by the person closest to the issue rather than by the person whose job title best matches the perceived difficulty of the task. "With a priority queue, you have a dumping-ground for any and all ideas (and bugs) that people suggest as the project unfolds. No engineer is ever idle, unless the queue is empty, which by definition means the project has launched. Tasks can be suspended and resumed simply by putting them back in the queue with appropriate notes or documentation. You always know how much work is left, and if you like, you can make time estimates based on the remaining tasks. You can examine closed work items to infer anything from bug regression rates to (if you like) individual productivity. You can see which tasks are often passed over, which can help you discover root causes of pain in the organization. A work queue is completely transparent, so there is minimal risk of accidental duplication of work." [1] http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
  - bernardlunn 15y ago
    "good agile" work queue sounds a bit like how good open source works and that might be scalable even for commercial and enterprise. The problem with some agile is it does not scale, so managers invent some process that is a bit waterfall-like and that turns into a kludgey mess.
    - dkarl 15y ago
      Exactly. Agile does not scale to the problems management wants to apply it to, so they rip it to pieces to make it fit. We have features contractually committed before development even starts, months-distant deadlines with predetermined deliverables, products with multiple owners, and scrum teams where people have the barest understanding of the work that their teammates do. We even have inter-team dependencies that mean any change of direction by a team will hang other teams out to dry (and what is more essential to agility than the ability to change direction?) A well-managed waterfall process would beat the hell out of the travesty of Agile that we practice now. But nothing would fix the bogus and stunting idea of a division of labor between "architects" and "developers."

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.

dpritchett 15y ago
I think you're describing what Steve Yegge called "good agile" [1]. Each task is handled by the person closest to the issue rather than by the person whose job title best matches the perceived difficulty of the task. "With a priority queue, you have a dumping-ground for any and all ideas (and bugs) that people suggest as the project unfolds. No engineer is ever idle, unless the queue is empty, which by definition means the project has launched. Tasks can be suspended and resumed simply by putting them back in the queue with appropriate notes or documentation. You always know how much work is left, and if you like, you can make time estimates based on the remaining tasks. You can examine closed work items to infer anything from bug regression rates to (if you like) individual productivity. You can see which tasks are often passed over, which can help you discover root causes of pain in the organization. A work queue is completely transparent, so there is minimal risk of accidental duplication of work." [1] http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
- bernardlunn 15y ago
  "good agile" work queue sounds a bit like how good open source works and that might be scalable even for commercial and enterprise. The problem with some agile is it does not scale, so managers invent some process that is a bit waterfall-like and that turns into a kludgey mess.
  - dkarl 15y ago
    Exactly. Agile does not scale to the problems management wants to apply it to, so they rip it to pieces to make it fit. We have features contractually committed before development even starts, months-distant deadlines with predetermined deliverables, products with multiple owners, and scrum teams where people have the barest understanding of the work that their teammates do. We even have inter-team dependencies that mean any change of direction by a team will hang other teams out to dry (and what is more essential to agility than the ability to change direction?) A well-managed waterfall process would beat the hell out of the travesty of Agile that we practice now. But nothing would fix the bogus and stunting idea of a division of labor between "architects" and "developers."