We all have some knowledge of the SDLC (aka “The cluster-fuck I call work”) but many of us work within the process (Design, Code, Test, Build, Test, Release, Repeat).  What we don’t see or understand is how the SDLC is perceived by and affects the business or outside world. 

Jezz Santos wrote a very thorough explanation (The Vicious Software Development Cycle) of his perception of the interaction between the software owner (the business) and the SDLC (the geeks).  Right or wrong, he has a significant number of valid points in his post that I’d like to touch on too.

Jezz starts off by touching on two things; Technology is Advancing Rapidly and Software Product Development is not Advancing.  He’s right, the technology (platforms, tools, environments, and other sundry geek stuff) is advancing at pace that is unimaginable.  Last year was astounding (see VS2k5, SQL2k5 and AJAX/Web 2.0 as prime examples) for new stuff to keep the geeks glowing and single.  All companies now are going to be bombarded with marketing fluffsters making claims like “VSTS will increase our teams productivity and ultimately lower the cost of development.”  This leads me to the fact that Software Product Development is not Advancing.  We have all these old and new methodologies (RUP, Waterfall, Extreme) but when you get right down to the nitty gritty, we still have problems in the fundamentals.  Some of the methodologies have tried to address this, but we still end up with missed/incorrect specs, piss-poor-programming-practices (today’s alliteration) and poor time line planning.  In the end we spend so much time trying to keep up with the avalanche of new technology and very little time addressing the fundamentals of software development.

In the end we find ourselves living in an industry where Customer Satisfaction is Declining.  In my mind we are in the realm of the airline industry.  We offer no value (“What the customer wants, and what the customer gets are two completely different things.”), we’re tardy and we hit you with hidden costs (airport improvement fee meet change request).

Now don’t think I’m all doom and gloom about the industry.  If I were I’d be comparing it to the Steamship’s of yester-year.  We’re at a prime point to pick ourselves up and get pointed in the right direction again.  I challenge you, and myself, to start with yourself. 
First write good, solid code. 
Next, give reasonable estimates for completion. 
Thirdly, ask questions of the client, get to know how they do things and keep those needs in mind when writing specs or doing system design. 
Finally, don’t get caught up in the hype of any tool.  Each tool has its use, but none are a silver bullet.