

Why Software Engineering Sucks - bkrausz
http://nerdlife.net/2009/01/23/why-software-engineering-sucks/

======
bprater
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
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. 

------
azanar
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. 

------
Zerotao
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. 

------
izak30
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. 

------
known
Software Engineering ! = Software Science

------
sarvesh
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.