Geeks With Blogs

The Lanham Factor The (ir)rational thoughts of a (not-so)mad man

For years, I have fussed (and that's putting it mildly) about the state of software development.  I have no end to my frustrations about trying to build software correctly while managers directors and such just want me to "code something".  In the last several months, a few colleagues and I have started sharing emails about work-related frustrations on this topic.  One of my recurring points is that we have no one to blame but ourselves.  Oh I'm sure you, the reader, always capture requirements and always test everything.  (Oh too!). 

Joking aside, we really have only to blame ourselves as a profession (not as individuals).  Recently I was working with a former client.  He asked me to stop by for a few hours of architecture & design discussion.  While discussing database design and implementation he made the comment that (and I'm paraphrasing) "...should probably use schemas and sub-schemas but I don't know how to do that and I don't have time to learn."

Don't have time to learn?  So here is another example of someone who was raised in the software arts with the belief that software development is at least 80% coding.  Couple that with the fact that he has no project manager, he probably doesn't have time.  The sales person is out there selling and the coders are back there coding whatever is sold.

So what is it about us that we must blame?  NOTE:  If you are reading this you probably don't need to read this.

Poor Analogies & Comparisons - For some reason, we tend to compare software development to construction.  Nothing could be further from the truth.  Years ago I read a comparison of software development with movie making.  Coders are like actors.  If that's all you have then you are missing directors (project managers), producers (stakeholders), script writers (business analysts), set designers (network administrators), camera operators (configuration managers), editors (QA & testing folks), etc. etc.  I love this analogy and use it often. 

I think there is also a comparison with pharmaceuticals.  The first pill costs $4M but every pill thereafter costs $0.25.   Software development is like this.  If you want to compare it to, say, car manufacturing then software development is more like the engineering process.  It can take as long as seven (that's "7") YEARS to engineer a car.  AND, engineering a car includes more than just designing the car (vis-a-vis software architecture and design), it also includes how the vehicle will be manufactured (vis-a-vis configuration management).  Where will the raw materials be obtained?  How will the car be assembled and in what order?

Ease - Let's face it, it is really easy to get going on writing code.  Most of the major "development" environments have a free and/or open source version (Visual Studio Express, Eclipse, Zend, etc.).  As such, people get started on the coding aspect and can easily turn-out a nice Web site or a few utility apps.  Then, when major application development comes along, they think it's just more coding.  Besides, coding is WAY more fun that all that other stuff.

So when someone asks them to build a small system they do, and for good money.  Then, when larger systems come along things go poorly.  Why?  Because no consideration was given to architecture, reuse, requirements, proper testing, etc.  And why is this?  Because no one ever told you that building software is more than writing code.  The industry is replete with examples of code, and how-to's for this feature or that.

Attitude - Software folks LOVE to show off their work.  And we are an instant gratification society.  Combine these factors and BAM!  That's a recipe for short-sighted software. We love to take the "can-do-in-a-weekend" attitude.

Writing code is generally the easy part.  I'm not even talking about writing code that "withstands the test of time".  I'm talking about writing code that doesn't hard-code everything...that is modular enough to be maintained by other developers.

Under promise - Over deliver.  Stop, for just a minute, thinking about how you will look and think about how the next person will look when they have to add a completely new subsystem to your application and can do it in under 4 hours.

Perspective - Whether you work in an IT shop, as a consultant, or for a software development company, you need to have the right perspective.  If you think you make software at your job, let me dispell that disillusion for you

You do NOT make make MONEY.

Software can be the engine that allows you to make money.  For you IT folks out there, the business you support makes money so you need to consider that when making development decisions.  The more money you make, the more fun you'll have.  The more you can spend on R&D or whatever. 

If you want to be a hobbyist, do that on your own time (I think that's part of the definition of "hobby").  If you want to be a research scientist, get a job doing that.  You can strike a balance between "good for me" and "good for the company". 

Training and Education - I'll admit that our companies' typically do a bad job of sending us to training and conferences and such.  That aside, be sure to take some professional responsibility for yourself.  Read magazines (industry-related :) ).  Attend user group meetings.

Also, take some time to educate your management team.  There is plenty of literature available to indicate that software development is more than just writing code.


Well, that's my rant.  If you are in software development, and you are frustrated with the state of software development, then I encourage you to stop waiting on non-technical people to change.  They are NOT going to suddenly awaken one morning and know how to build software and come in to the office and say

"Hey, Suzie!  I've been thinking we should extend the deadline by six weeks so we can implement an abstraction layer around the accounting system.  That will give us the flexibility to change our accounting system AND connect many other applications to it allowing us to grow as a business.  I think Phil was working on an asynchronous messaging service implementation.  Why don't you check with him?"

So take it upon ourselves. 

Posted on Wednesday, July 18, 2007 6:24 AM SILC - Solution Implementation Life Cycle | Back to top

Comments on this post: We Can Only Blame Ourselves

# re: We Can Only Blame Ourselves
Requesting Gravatar...
I recommed reading the book "My Job went to India and all I got was this lousy book".
Left by Gabriel Lozano-Moran on Jul 18, 2007 8:14 AM

Your comment:
 (will show your gravatar)

Copyright © Brian Lanham | Powered by: