3 ms·

> ... Architects, Test Designers... The two examples you use, would have to be the best examples of 'waste' in the software industry. I liken them to having s

by Volpe 15y ago

> ... Architects, Test Designers... The two examples you use, would have to be the best examples of 'waste' in the software industry. I liken them to having someone on your team who is "The Debugger" where all he does is debug the developers code. Developers should know how to test their code/app and should know how to design their app, and know how to debug their app. Sure they could 'specialise' one or more of these areas but they should all be able to build software (i.e write code).

nl 15y ago
Specialization is an adaptation that seems wasteful when it isn't needed but makes a huge increase to efficiency when it is. Yes, architects and test designers can be a waste. But they can also act to make developer's lives easier. Good architects can code, but usually act at a higher level - making sure different projects (a) know about each other, and (b) work together. That's important because teams tend to focus on their own success without always taking account of the bigger picture.
- Volpe 15y ago
  > Good architects can code... Is synonymous with good developers are also good architects. I think (if I can articulate my thoughts correctly) my meaning was, that there is an obsession with breaking tasks into specific roles that are then the sole responsibility of one person. To the point of inefficiency (given the number of people you have to talk to for a given feature). I don't agree that specialisation is wasteful (for the project at least). If it isn't needed, the person can still be a 'standard' dev. But if it is needed, they contribute more. (The only waste is to the individual if they specialise in an un-needed skill).
  - johnx123-up 15y ago
    > Is synonymous with good developers are also good architects. But, most architects are lazy genius. Only way to utilize their skills is not allowing them to code, but letting them designs and coach.
wnight 15y ago
I agree. Architects should just be senior coders - the people whose strategic decisions are usually right (mostly because they know how to test their assumptions). Having a specific person who doesn't do anything else but architect is broken - APIs are for programmers. If you aren't eating your own cooking you have absolutely no right to be claiming you did it well. Similarly, you could hire a developer on the strength of their testing and get them to champion a stronger infrastructure but like the architect they need to be an active developer to judge the usefulness of their solutions. I'd say managers (of coders) need to be coders too. They can survive not being if they're great managers, but they're doing it with a handicap of not being able to understand the tools and see the big-picture their team is missing. And the state of the art, not whatever they used in school twenty years ago. But, conversely I think I was a lousy employee early on (in terms of value created for the core product / hours spent) because I wasn't thinking of the business aspects of the company. So while I think everyone needs active programming skills to participate meaningfully in programming, I also think those programmers need to be aware of the business they're in, the entire industry trends, and that of the problem domain the work is in. If you design/make/sell a farming GPS, for instance, you'd better have farming experience. Perhaps the loosely overlapping networks of broadly-skilled individuals managing their own (but with input from an on the rest of the company) doesn't scale well, but I've yet to see a better idea.

by Volpe 15y ago

nl 15y ago

Specialization is an adaptation that seems wasteful when it isn't needed but makes a huge increase to efficiency when it is. Yes, architects and test designers can be a waste. But they can also act to make developer's lives easier. Good architects can code, but usually act at a higher level - making sure different projects (a) know about each other, and (b) work together. That's important because teams tend to focus on their own success without always taking account of the bigger picture.

Volpe 15y ago
> Good architects can code... Is synonymous with good developers are also good architects. I think (if I can articulate my thoughts correctly) my meaning was, that there is an obsession with breaking tasks into specific roles that are then the sole responsibility of one person. To the point of inefficiency (given the number of people you have to talk to for a given feature). I don't agree that specialisation is wasteful (for the project at least). If it isn't needed, the person can still be a 'standard' dev. But if it is needed, they contribute more. (The only waste is to the individual if they specialise in an un-needed skill).
- johnx123-up 15y ago
  > Is synonymous with good developers are also good architects. But, most architects are lazy genius. Only way to utilize their skills is not allowing them to code, but letting them designs and coach.

wnight 15y ago

I agree. Architects should just be senior coders - the people whose strategic decisions are usually right (mostly because they know how to test their assumptions). Having a specific person who doesn't do anything else but architect is broken - APIs are for programmers. If you aren't eating your own cooking you have absolutely no right to be claiming you did it well. Similarly, you could hire a developer on the strength of their testing and get them to champion a stronger infrastructure but like the architect they need to be an active developer to judge the usefulness of their solutions. I'd say managers (of coders) need to be coders too. They can survive not being if they're great managers, but they're doing it with a handicap of not being able to understand the tools and see the big-picture their team is missing. And the state of the art, not whatever they used in school twenty years ago. But, conversely I think I was a lousy employee early on (in terms of value created for the core product / hours spent) because I wasn't thinking of the business aspects of the company. So while I think everyone needs active programming skills to participate meaningfully in programming, I also think those programmers need to be aware of the business they're in, the entire industry trends, and that of the problem domain the work is in. If you design/make/sell a farming GPS, for instance, you'd better have farming experience. Perhaps the loosely overlapping networks of broadly-skilled individuals managing their own (but with input from an on the rest of the company) doesn't scale well, but I've yet to see a better idea.