Showing posts with label sdlc. Show all posts
Showing posts with label sdlc. Show all posts

Friday, November 20, 2009

Software Engineering Rediscovers “The User”

I've lost count of all the white papers, symposiums, books, journal articles, web articles, blog postings and tweets that espouse the virtues of software engineering in the scientific and technical sense. Every now and then (rarely) does one delve into the more artistic aspects.  But never have I seen a thorough inspection made of the customer or "end-user" aspects.  They are always discussed as either an after thought or as if they're some necessary piece of machinery in the SDLC assembly line.  This is sad.  Really sad.

I'm really shocked and disappointed at how the software architecture / engineering / development world has decided to close the door and put on their white lab coats.  Software is being developed in a close-minded bubble.  This was not always the case.  In fact, when I started writing software programming code in the early 1990's, the norm was meeting end-users "face-to-face" and hashing out needs/wants/concerns and ideas in person.  You know, the same way you argue with your mechanic when he says it's going to cost you $9000 to replace something you've never heard of.  Users are your lifeline.  They feed your products, your projects, indeed: your career.  I can't believe how this has morphed into such a sucky situation.  The best these multi-billion dollar software companies can do now is stand up a CMS portal or a bulletin board and some emails.  Would a phone call kill you?  Heck, even a personal e-mail?  Form-driven e-mail auto-responders are for dickheads.  They say to the user/customer "you are a number, give us what we want and go get lost".

I no longer write software as my primary means of earning a living.  I still do it as a side role at work and for a few long-time clients and friends, as well as for myself at home.  I remember clearly how the CMMI, SDLC, ISO, SOX, FISMA, HIPAA mindset grew from tiny seeds and into a forest of confusing trees with reams and reams of documentation aimed at MBA's to decipher.  There was once a term we used that seems to have died and turned to dust.  It was "common sense".  Here's how it used to work, and how it should still work (because it worked fine before):

1. Figure out what the user's problem is that you want to help solve
2. Work with the user to find the solution
3. Work with the user to improve the solution
(Repeat from step 1)

In all three of these is the word "user".  It's also an "iterative" process.  Did you know that "iteration" has usefulness outside of programming statements?  Amazing.  Did you know that you can improve a product or process simply by revisiting the above steps until there are no more problems to solve?  Amazing as well.

Some companies still get this.  But it's taken a crashing economy and job losses to make it happen.  To me, this is sort of like how you remember how to hunt and fish when a disaster strikes and destroys all the modern conveniences like grocery stores, restaurants and you run out of canned and frozen crap.  Oh yes, survival, that funny word.  Business survival is making companies do all sorts of crazy things.  Things like talking to customers whom they have ignored for the past ten years. Actually asking for input on their next product version.  Silly, radically insane things like this.  (giggles)  Ha ha.  Have you noticed? Those that aren't getting on the wagon are those who are heading for a cliff.

Whatever the reasons or rationale, it's both comforting and ironic to see this return to "caring for the customer" by software vendors.  For so long they've been shut in their labs and masturbating to copies of SDLC Weekly; Convinced that they already knew what problems their customers were facing and how best to solve them, all without ever asking the user directly.  So, for all you education text writers out there working on your shlock to sell to the universities and community colleges: Don't forget to devote at least a sentence or two to the importance of "users".  While IT folks like to joke about "users are losers", they are as important to your goals as the software itself.

Monday, July 28, 2008

What have CMMI and SOX solved for us?

Nothing. I don't see any drop in bugs, nor any substantial "quality" improvement in software that can be directly attributed to CMMI. Not even to SOA or SDLC crap. That's all MBA stuff. Good code writing is good code writing. It's 50/50 artistry and technical skill, mixed in a smooth blender with crushed ice and a cup of tequilla. Trying to stuff that into a box with warning labels and procedures on the outside hasn't done squat to improve things. The code has improved by learning what works and what doesn't. Sorry, a rant sparked from someone trying to defend CMMI and SDLC as making for better products. I don't buy it. It's snake oil peddled by consulting firms to big corporations to spend gobs of money chasing forever.