Skip to main content

Most Software Development Obstacles are ______

Posted by johnreynolds on July 27, 2008 at 6:30 PM PDT

Fill in the blank in the following statement:

Most Software Development Obstacles are ______
(A) Technical
(B) Cultural

If you answered (A), then I am intensely jealous :-)

When I became a programmer, my answer definitely would have been (A) and I probably wouldn't have had a clue why (B) was even on the list. I doubt that I had any idea what "Cultural Obstacle" even meant in the context of Software Development.

I was drawn to programming because of the technical challenges (I love solving puzzles and building things). My University classes (except for electives) all of the classes that I took at the University were concerned with Science and Engineering. Now I realize that I should have taken some basic classes on Psychology.

Let me give you one example:

The implementation methodology that I practice and the one that I encourage others to practice can be expressed pretty simply:

Build "something that works" and start using it. Identify the next most iimportant thing to extend or enhance and then build and use that thing. Continue these cycles until everything is "good enough".

I now call this "iterative development"... but I use to call it "the shaft of light theory". Others might call it Agile.

I arrived at this approach pretty early in my career... as I think many of us do. I found myself working on overly ambitious projects that just seemed to drag on and on with no end in sight. Nobody knew what worked and what didn't. Everything on the project plan was 80 percent complete.

As deadlines approached we'd start dumping feature right and left until we got down to the stuff we could actually finish by the due date.

On top of that we'd often "finish" only to find that the output of our labors wasn't what the end user really wanted. Perhaps we had misunderstood or perhaps they had changed their minds. Regardless, nobody was happy despite our hard work.

I am a huge fan of "play backs"... Demonstrate the application to the users as you develop it to insure that what you are building is what they need. Often the requirements will change as the users become fully aware of what (you think) they asked for... and that's okay with me.
Admittedly, this approach won't work for everything... but for the jobs that I do (where there's a lot of human interactions) it works most of the time.

Most of the Quality Assurance people that I know hate my approach. How can they assure the Quality of the product if the requirements are in flux?

Look at QAs objections from a process perspective: one measure of a good process is the amount of necessary rework - less rework is good, more rework is bad.

From a QA perspective iterative development is bad because it requires them to do a lot of rework - testing "the same" functionality over and over. Prior to a production deployment everything must be tested, and in many cases even regression testing is foiled by new requirements.

From my perspective this is a small price to pay... It's more important to get "something" to the user as early as possible, and we're much more likely to build what they really need.
I have to admit that QA has a point though... Without a comprehensive plan from day one... How can you reliably estimate when you'll be done?

I've focused on QA and Development - but you know the same applies to Security, DB and Network Admins, etc. Each have their own jobs to do and their own ideas on how to do their jobs well.

There are no right answers here... It's a clash of cultures rather than a question of technical merit.

"Measure twice and cut once" versus "Shave off a little and see if it fits".

Both approaches "work"... But they don't work together.

What's crucial is for each organization to develop a culture that works for them. If you hire an Agile Development Manager then you'd better hire an Agile QA manager. Some might argue that it's good to have divergent viewpoints within an organization, but my experience has taught me that everyone is much happier (and everything works smoother) if the department heads agree on the fundamentals. I don't agree with executives who believe that underlings who fight with each other produce better results.

So what do you do when you find yourself working with others who disagree with your approach? What do you do when you disagree with their approach? My guess is that you've already dealt with these questions many times... sometimes with positive outcomes and sometimes with negative outcomes.

Hopefully your positive outcomes are on an upward trend... If not it may be a good time to reflect on "life, the universe and everything" and adopt a more effective approach for dealing with others.

They may be morons. They may be idiots. They may even be slackers and lazy. But I doubt it.
They probably just belong to a different culture than yours.

If you want to be an effective programmer, you are going to have to find a way of dealing with them - or your efforts will be wasted...

Welcome to the wonderfuil world of programming ;-)

Related Topics >>


Hi johnreynolds thanks for providing useful information on Software Development. Thanks MAG Studios

"when you assume technical and non-technical skills are in the same level of relevance for the quality of the production, you dismissed all your value as technician..." Developers valuing themselves too highly is a problem. There's more to writing great software than making sure the code works as intended. You have to make sure that what's intended is what users actually want! You don't learn what users want by reading Filthy Rich Clients or by combing through the entire source for Apache commons or by having a great agile development model. You learn what users want by hanging out with users. Most developers don't hang out with users. That's reserved for the non-technical guys for the most part. There's a lot of intelligence to be gained by listening and working with the guys on the front line. Usually those guys are non-technical. Usually their viewpoint about and appreciation for great software is different from the developers. Appreciating their intelligence makes developers look less aloof and less "code wise but customer stupid."

I'll bite on your jet analogy Felipe... What really matters is getting passengers to buy tickets on your airlines... Contrast JetBlue with the score of regional carriers.... If you ever fly them once, you will fly them whenever you can. The comfort of the passengers really does matter (I fly a lot: -JohnR

another analogy for you: imagine two old pilots talking about aviation and airlines business.. one of them say: "you know what, anyone can pilot a jet, it is quite easy .. what really matter in this business is the comfort of the passengers..." After few minutes, both pilots agree the waitress on board, the marketing campaign and all surrounding roles on aviation are more important toward the business success.. indeed pilots don't need much attention, they can be replaced anytime .. :)

...Do you really think Technical Merit alone is responsible for it's success?... In this point I completely agree with you, the problem I was talking about is where developers are reduced to mechanical workers... This is very common nowadays, and this is one of reasons why computing is loosing interest in the new generations.. And Apple and other billionaire businesses are always not a good example, because we never know if it succeeds by money or by quality :) anyway, just my 2 cents ;)

I have to disagree with you Felipe: "when you assume technical and non-technical skills are in the same level of relevance for the quality of the production, you dismissed all your value as technician" Take a look at the iPhone... Do you really think Technical Merit alone is responsible for it's success? I think one of the biggest differences between Steve Jobs and Bill Gates is Steve's appreciation for the non-technical, and that's a large factor in the success of his products. -JohnR

You've hit on a fundamental issue here John, there are two very different schools of thought: (or culture) * One says: clearly specify the design requriements, then lock them down, and implement to the specification. * The other says: get the basics working, and let the users/customer evaluate/comment/evolve it. The two methodologies, being on two different ends of the software design spectrum, are not very compatible. IBM is notorious for applying the first approach: in the beginning, the project specification is delivered to the customer for sign off, typically in no less than 5000 pages. The software will be delivered to a specific deadline, at a specific cost. After that, _every_ change "order" costs the customer, in both money and time, until finally the customer typically accepts software he doesn't really like, solely because he doesn't want to pay and wait for more changes. However, this is a very financially stable model for a software development company. Clearly I, and yourself, tend to favour the second approach, because the client is typically more pleased. Personally, I tell my team: "The codebase must always be ready to demonstrate." However, if a client feels free to change requriements, it must be remembered that these changes cost money and time to implement, and that had better be in the budget, it is very dangerous to do on a fixed-price/deadline basis. Unfortunately, the second approach is financially unstable most of the time. (What works best here, is a time/materials contract) It is well to understand both schools of thought, and that they are both valid. They are both actually "agile" in that they accomodate change; they just manage them differently. If you are assigned to a project, it is well to quickly ascertain which approach is taken by the team. Then you simply put on hat A or hat B, and get on with it. Normally you don't get a choice, and if you cannot change hats, then you are in for a lot of stress. Also, project teams who try to mix these two methodologies: they are in for a *tonne* of stress. Interesting topic, something about which primarily us "old-timers" ponder. (also) John

yep, maturity brings us more balance and patience, but just 1 point called my attention in your blog.. the trap about the values of each roles in the final product...

I agree with your view about different cultures and the need to understand and adapt instead of kick the wall..., but...

when you assume technical and non-technical skills are in the same level of relevance for the quality of the production, you dismissed all your value as technician...

More on that:

One of the biggest traps nowadays: technical people trying to rationalize the value of non-technical people on IT market.. at the end, some guy that studied Psychology or other useless field at university will take your salary.. while you will remain only with the complex algorithms and poverty :) think about that...