4 ms·

Why Software Engineering Sucks

7 points by bkrausz 18y ago

sarvesh 18y ago
Most of the brilliant teams I have worked with have a process but they are intelligent enough to follow things that make sense to them. Mindlessly applying a fat process without understanding why to any project is obviously illogical and bound to ruin the project.
Zerotao 18y ago
The author seems to confuse waterfall method with software engineering. Engineering means having a process not a specific process. His first example sounds very close to the team I currently work with if you add in constantly touching base with the origional stake holders. But we are still engineering, we still make controlled changes that we, as a team, determine are the best fit for the problem.
azanar 18y ago
There is another distinguishing factor about the Group 2s that I really wish the article had brought up; some of them honestly don't give a damn about the product. The product is an end-point, and after that they either need to find another project to work on or they become unemployed. Even if there will always be more work, the risk of appearing idle during a project transition, and thus redundant, looms always. So, the goal becomes pushing out that end-point as far as possible without making the project so impractical that it is canceled. This pile of process and paper is not a necessary evil to them, but something they want to actively encourage. If they could spend anywhere between 3 and 24 months having meetings, doing design specs, fleshing out requirements, and going through 2^n revisions of the same, they'll push for 24 months regardless. They don't do this to be actively malicious to the company or the product, but because they don't care about the company or the product. To them, it is just another job, and the point then becomes to keep it and get paid for doing it as long as possible.
bprater 18y ago
The authors paints with a brush that is entirely too wide for the canvas. He's a student with no real world experience in putting together a system. Because of that, it's easy to conclude that drones create software from reams of paperwork and ninjas wing it and hack it out in a few days with Coca-cola and Ramen. The real reality is that neither extremes is useful or done exclusively. Sitting down and putting at least some of the architecture down on paper can be useful. If you have a team larger than two people, it might be necessary to document some of the process so that people know what part they are playing. I wish him the best of luck -- he will be tempered to neither extreme after he's spent some time working in various places.
- jayair 18y ago
  His second example seems to be closer to reality than the first one. In reality you are likely to have a set of programmers (more than two) with varying levels and communication skills. Added to that as somebody else mentioned, this is just a "job" to most people and you are likely to have a team change over time (people move on or get laid off etc). Given this scenario it is more beneficial to have - Well defined initial requirements - Every item speced out - Proper class diagrams - Functional requirements - So much detail that even X can code it (where X is a current/future employee with a variable technical and communication skill and interest level). He additionally cites the case where he has personally observed "100 person companies" that manages to hire Group 1's. I am more interested in hearing about this case rather than read about his personal principles. "My personal principle is that if you’re not smart enough to be able to communicate well and produce good code without a strict formal process, I don’t want to be working with you." I am still trying to figure out how somebody could use a strict formal process to overcome the disability to produce good code.
known 18y ago
Software Engineering != Software Science
izak30 18y ago
While he might be right, it's still not practical to group things in this way, and when working on a project with more than one person, you should always document things correctly etc. If not, it will allow what he calls 'mediocre' programmers to determine that they are brilliant, and quit documenting.

7 points by bkrausz 18y ago

Most of the brilliant teams I have worked with have a process but they are intelligent enough to follow things that make sense to them. Mindlessly applying a fat process without understanding why to any project is obviously illogical and bound to ruin the project.

Zerotao 18y ago

The author seems to confuse waterfall method with software engineering. Engineering means having a process not a specific process. His first example sounds very close to the team I currently work with if you add in constantly touching base with the origional stake holders. But we are still engineering, we still make controlled changes that we, as a team, determine are the best fit for the problem.

azanar 18y ago

There is another distinguishing factor about the Group 2s that I really wish the article had brought up; some of them honestly don't give a damn about the product. The product is an end-point, and after that they either need to find another project to work on or they become unemployed. Even if there will always be more work, the risk of appearing idle during a project transition, and thus redundant, looms always. So, the goal becomes pushing out that end-point as far as possible without making the project so impractical that it is canceled. This pile of process and paper is not a necessary evil to them, but something they want to actively encourage. If they could spend anywhere between 3 and 24 months having meetings, doing design specs, fleshing out requirements, and going through 2^n revisions of the same, they'll push for 24 months regardless. They don't do this to be actively malicious to the company or the product, but because they don't care about the company or the product. To them, it is just another job, and the point then becomes to keep it and get paid for doing it as long as possible.

bprater 18y ago

The authors paints with a brush that is entirely too wide for the canvas. He's a student with no real world experience in putting together a system. Because of that, it's easy to conclude that drones create software from reams of paperwork and ninjas wing it and hack it out in a few days with Coca-cola and Ramen. The real reality is that neither extremes is useful or done exclusively. Sitting down and putting at least some of the architecture down on paper can be useful. If you have a team larger than two people, it might be necessary to document some of the process so that people know what part they are playing. I wish him the best of luck -- he will be tempered to neither extreme after he's spent some time working in various places.

jayair 18y ago
His second example seems to be closer to reality than the first one. In reality you are likely to have a set of programmers (more than two) with varying levels and communication skills. Added to that as somebody else mentioned, this is just a "job" to most people and you are likely to have a team change over time (people move on or get laid off etc). Given this scenario it is more beneficial to have - Well defined initial requirements - Every item speced out - Proper class diagrams - Functional requirements - So much detail that even X can code it (where X is a current/future employee with a variable technical and communication skill and interest level). He additionally cites the case where he has personally observed "100 person companies" that manages to hire Group 1's. I am more interested in hearing about this case rather than read about his personal principles. "My personal principle is that if you’re not smart enough to be able to communicate well and produce good code without a strict formal process, I don’t want to be working with you." I am still trying to figure out how somebody could use a strict formal process to overcome the disability to produce good code.

known 18y ago

Software Engineering != Software Science

izak30 18y ago

While he might be right, it's still not practical to group things in this way, and when working on a project with more than one person, you should always document things correctly etc. If not, it will allow what he calls 'mediocre' programmers to determine that they are brilliant, and quit documenting.