4 ms·

When software projects fail, it's natural to think "wow, if only we had organized things in this way...", or "if only we had a more accurate schedule...", but i

When software projects fail, it's natural to think "wow, if only we had organized things in this way...", or "if only we had a more accurate schedule...", but it's just a way of ignoring the elephant in the room: your developers weren't up to the task. Think about it this way: if your developers knew about all of the issues that would result in a failed project and a) didn't tell you or b) didn't quit if you ignored their warnings, then what kind of professional developers are you employing ? This micro-management of the entire software development process is completely unnecessary and contrary to every bit of real-world evidence that we have about what has made certain software projects successful, and others not. Ambition, drive, and a penchant for excellence is what makes great software, not a bunch of managers pushing along a group of mediocre developers like cattle.

humanrebar 9y ago
> This micro-management of the entire software development process... I've been there. I've also been in the opposite, where there really is no technical leadership. I can't say it's better. For what it's worth, certain agile techniques do provide a structured way to make clear group decisions. Unfortunately those decisions usually revolve around development methodology and not, you know, the design of the actual product. Point being, micro-management is often a broad reaction to a vacuum of technical leadership. But instead of innovating, with the team makeup in mind, on how to make sure good decisions emerge, a manager will figure they need to personally make those decisions. So they need more structure to make sure they're better informed, and agile techniques tend to get hijacked to that end.
- TimJYoung 9y ago
  Yes, but that's my point. If you have a lack of technical leadership, then you need a different set of developers and need to look at who you're hiring as developers, not whether you need more management of the group of developers. For the cost of a technical manager, you can add quite a bit of salary to each developer position in a small group.
itsdrewmiller 9y ago
Hardly anyone is going to quit just because you ignore their warnings and let them work on a project doomed to fail, barring a significant equity stake. Software projects fail due to bad management, not (solely) bad developers; you go to war with the army you have.
- TimJYoung 9y ago
  Would you spend a year or more on a project that you knew was going to fail 2-3 months in to the project ? I certainly wouldn't, but maybe I'm in the minority. It certainly doesn't look that great on one's resume...
  - eesmith 9y ago
    Really? I'm sure some would regard it as an example of professionalism, "going down with the ship", "when the going gets tough ...", etc. Some people would jump at the change to learn a new technology on the company's dime, if they know that the project failure can't be attributed to them. Eg, a front-end engineer could say "we developed an Angular2 front-end which was on-time and tested well, but the back-end engineers failed to <insert failure here>." Do project failures really look that bad? Kent Beck and Ron Jeffries famously employed worked on the Chrysler Comprehensive Compensation System, which helped establish Extreme Programming. https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... What does it mean then that after the first delivery, the project's customer representative was burned out and couldn't be replaced, the software was only ever used for 10,000 of the 87,000 people it was supposed to be used for, but even with the smaller number it still took 9 hours to run, and new developed stopped two years later, never reaching the original design goal? If project failures look bad, how is it that XP ends up with such a good reputation?
    - TimJYoung 9y ago
      Sorry for not replying sooner, I missed your reply. I should have been more specific about the context: I'm talking about failed projects that were doomed from the start, and known to be in such a state by those that were involved. There are many (most ?) projects that look okay right up until the implementation when all the problems become visible. Those types of projects are fertile grounds for learning from experience, and I would categorize them as valuable experiences. Obviously if a developer is in a junior position in a project that encompasses a small army of developers, then they may not have any problem with staying on with such a project. But, I would gather that these types of projects are pretty rare, and that most projects involve much smaller teams. In such an environment, the stress and toll on one's family life and health aren't worth sticking around for, even for any learning experience that one may gather from the failure. It's a much better situation to simply learn the involved technologies on one's own in your spare time than subject oneself to that level of harm.

humanrebar 9y ago

> This micro-management of the entire software development process... I've been there. I've also been in the opposite, where there really is no technical leadership. I can't say it's better. For what it's worth, certain agile techniques do provide a structured way to make clear group decisions. Unfortunately those decisions usually revolve around development methodology and not, you know, the design of the actual product. Point being, micro-management is often a broad reaction to a vacuum of technical leadership. But instead of innovating, with the team makeup in mind, on how to make sure good decisions emerge, a manager will figure they need to personally make those decisions. So they need more structure to make sure they're better informed, and agile techniques tend to get hijacked to that end.

TimJYoung 9y ago
Yes, but that's my point. If you have a lack of technical leadership, then you need a different set of developers and need to look at who you're hiring as developers, not whether you need more management of the group of developers. For the cost of a technical manager, you can add quite a bit of salary to each developer position in a small group.

itsdrewmiller 9y ago

Hardly anyone is going to quit just because you ignore their warnings and let them work on a project doomed to fail, barring a significant equity stake. Software projects fail due to bad management, not (solely) bad developers; you go to war with the army you have.

TimJYoung 9y ago
Would you spend a year or more on a project that you knew was going to fail 2-3 months in to the project ? I certainly wouldn't, but maybe I'm in the minority. It certainly doesn't look that great on one's resume...
- eesmith 9y ago
  Really? I'm sure some would regard it as an example of professionalism, "going down with the ship", "when the going gets tough ...", etc. Some people would jump at the change to learn a new technology on the company's dime, if they know that the project failure can't be attributed to them. Eg, a front-end engineer could say "we developed an Angular2 front-end which was on-time and tested well, but the back-end engineers failed to <insert failure here>." Do project failures really look that bad? Kent Beck and Ron Jeffries famously employed worked on the Chrysler Comprehensive Compensation System, which helped establish Extreme Programming. https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... What does it mean then that after the first delivery, the project's customer representative was burned out and couldn't be replaced, the software was only ever used for 10,000 of the 87,000 people it was supposed to be used for, but even with the smaller number it still took 9 hours to run, and new developed stopped two years later, never reaching the original design goal? If project failures look bad, how is it that XP ends up with such a good reputation?
  - TimJYoung 9y ago
    Sorry for not replying sooner, I missed your reply. I should have been more specific about the context: I'm talking about failed projects that were doomed from the start, and known to be in such a state by those that were involved. There are many (most ?) projects that look okay right up until the implementation when all the problems become visible. Those types of projects are fertile grounds for learning from experience, and I would categorize them as valuable experiences. Obviously if a developer is in a junior position in a project that encompasses a small army of developers, then they may not have any problem with staying on with such a project. But, I would gather that these types of projects are pretty rare, and that most projects involve much smaller teams. In such an environment, the stress and toll on one's family life and health aren't worth sticking around for, even for any learning experience that one may gather from the failure. It's a much better situation to simply learn the involved technologies on one's own in your spare time than subject oneself to that level of harm.