Developer Myopia

While some may argue that TDD, BDD, SRP, ahderence to SOLID, use of Patterns, and many other development practices and principles are critical to achieving great software, these all seem to miss some core truths.

Most Software Has Not Been Developed This Way

Yep, sorry to disappoint, but the vast majority of software in production in the world today has had none of these principles and practices applied. Some of the software may have had some of these practices applied - but it is (I would guesstimate) an incredibly small percentage.

And despite that (feel free to tell me I'm wrong) fact, most software works and continues to work. It processes your taxes correctly, makes sure your airplane doesn't blow up on take off, scans your body for cancer, lets you bill your customers, tells you what you are doing tomorrow, and lets you keep in touch with friends and family.

Most Software "Mistakes" Are Not Development Practices

Steve McConnell, he of Code Complete and Rapid Development fame (books everyone in development or management should read) has just published his "Software's Classic Mistakes" list for 2008, and none of these things we developer's like to refer to as "best practice" or "the right way" feature on the list - not in their specific forms, mnor even in their general forms.

In fact - all of the classic mistakes (which cause software projects to be delayed or fail) are process mistakes, they are failures of people, not of coding constructs and practices.

  • Unrealistic Expectations
  • Overly Optimistic Schedules
  • Shortchanged Quality Assurance
  • Wishful Thinking
  • Confusing Estimates With Targets
  • Excessive Multi Tasking
  • Feature Creep
  • Noisy Crowded Offices
  • Abandoning Planning Under Pressure
  • Insufficient Risk management

We can certainly look at this list and see how Agile, Lean and similar processes can help alleviate many of these, but where do you see "TDD", "BDD", "SOLID" or even "Automated Testing" resolving any of them? The closest we will come is to see "Shortchanged Quality Assurance" as being ticked off the list, but this still doesn't remove the need for real QA on a project, and real QA people.

Developer Myopia

While as developer's we see great value in many of these practices, we need to admit that we are actually a very small part of the equation, and sometimes developer myopia sneaks in - we think that what we do at a code level matters, substantially more than it does in the grand scheme of things.

By all means, apply and practice these things that create "quality" software, but bear in mind, there are much bigger and more important problems to resolve too.

Or to paraphrase (and bastardize) the Agile manifesto: While we see value in software patterns and practices, there is more value in solving process problems first

 


Posted 10-05-2009 1:07 PM by Jak Charlton

[Advertisement]

Comments

Jeremy Likness wrote re: Developer Myopia
on 10-05-2009 9:12 AM

This one I'm going to have to say ... prove it. It's quite a stretch to say a "core truth" is that most software has used absolutely none of those principles.

Can you site an example?

You are talking about taxes, airplanes, and bill pay, and telling me all of those applications just got thrown together by cowboy coders?

I'm having a tough time swallowing that one. Yeah, there are bigger picture items, but to say that a list of "classic mistakes" proves these aren't used is quite a leap, isn't it? Maybe the reason the list is that way is precisely because the practices were used, so the flaws ended up somewhere else in the pipe/chain/hierarchy?

I'm just really interested to see any sort of basis for assuming processes aren't used on a wider scale, other than just a wild blog post claim. Sounds a lot like "duct tape" programming post ... let's go against the grain just to go against the grain without some tangible evidence to support it.

Daniel Fernandes wrote re: Developer Myopia
on 10-05-2009 11:23 AM

@Jeremy Likness  

Jak is being cynical in its usual ways, but I guess what he's talking about is about lack of perspective from a lot of developers who think that only the latest methodologies/principles/patterns/technologies can solve problems that could be solved with thorough human testing and/or bespoke automated testing.

There is indeed *a lot* of software out there built on 100s of pages of technical requirements and sometimes our lives depend on them.

Those systems, usually costly, relied on thorough human testing and probably used bespoke testing techniques too such as full scale demos using systems completely replicating live systems.

I think the difference between then and now is that a lot more software gets written and the overall pace of technical change is much faster, hence the emergence on new those new methodogies fit for these kind of environments.

Daniel

Steve wrote re: Developer Myopia
on 10-05-2009 1:59 PM

Considering I was part of what started this whole stupid arguement, I guess I'll comment.  I still don't think that Scott knows what my concerns were even after making it abundently clear over and over again.  I think he's the type of guy who sees what he wants to see (that I was somehow attacking TDD) so he can make another blog post.

I think Jak nails it right on the head here, that the developers really aren't all that important in the success or failure of a project.  When they do have impact, it's the quality of the code that matters, not how they achieve that quality.  TDD, BDD, or any other flavor of the month achronym  in no way produces good code, good developers produce good code.  Good developers also tend to use SOLID, DRY and YAGNI, not because they are cool, new tools, but because they make sense, and let's face it, are very easy to do.

TDD, BDD, et al on the other hand?  Not so easy, they fundementally change the way you work, so for some people they have a negative impact.  So we shouldn't be surprised to find out that not everyone wants to follow them.

Also, @Jeremy Likeness, are you saying that the author of this post has to prove that most software has been written without TDD, BDD, SOLID, etc.?  So, by saying that are you saying that you feel most software is written using "core" principles?  Because otherwise, I have no idea what your point is.  Anyone who has either job hopped or who enjoyed the golden age of consulting (how I miss thee) will tell you that the vast majority of applications they've seen adhere to little (if not any) of the "core" principles.  Is that proof?  No, because the sort of proof you want isn't possible to acquire.  I can tell you that I've done work for over 20 companies, most of which are world leaders in their respective fields, and the code is pretty much, universally bad.  Take that for what it's worth.

Diogo Mafra wrote re: Developer Myopia
on 10-05-2009 2:15 PM

I agree with you, the process is VERY important.

Most of the problems can be avoided by having a fast feedback. If they aren´t avoided, at least they are solved early. Agile practices helps us to do that.

I think that, some practices like TDD and SOLID Principles are necessary to allow fast changes and gradual evolution of the system.

Lee Brandt wrote re: Developer Myopia
on 10-05-2009 2:17 PM

My understanding was that (SOLID and DP at least) were kind of a study of best software already written. The point was that upon closer inspection, well-written software exhibited these kinds of practices.

As for TDD/BDD, the two biggest values I get out of it, are: viewing my code from the consumer's point of view, and the low-level regression suite that's left behind means, I don't have to fire up the app and go through the entire thing again to check to make sure my latest changes haven't broken anything. Alt+T runs my test suite and I can be sure that everything that was tested is still working in a few seconds. There is certainly a learning curve, but the benefits tend to outweigh the initial slow down. At least it did for me. Now, I think I code faster with "specs" to guide my way.

FWIW - Lee

Steve wrote re: Developer Myopia
on 10-05-2009 2:19 PM

Diogo,

I'm not disagreeing, but I'm more curious. Why do you think TDD is necessary to allow fast changes?

Diogo Mafra wrote re: Developer Myopia
on 10-05-2009 2:51 PM

Steve, for me TDD helps in the design, reducing the class coupling and if I have to do any change in the system the tests help me to be sure nothing else breakes.

I know this is not a rule. But, for me, those practices help allowing to be more agile.

Awkward Coder wrote re: Developer Myopia
on 10-05-2009 4:13 PM

@Diogo

TDD is about TEAM work not the individual, if you work in isolation (in a team) or solely on your own then TDD is going to be any faster to make changes, but if you're in a team it gives all members a level of certainty about the code and therefore reduces time & cost of development...

of course this is just another opinion...

Scott wrote re: Developer Myopia
on 10-05-2009 4:31 PM

sigh.

Awkward Coder wrote re: Developer Myopia
on 10-05-2009 4:36 PM

should have read...

' then TDD isn't going to be any...'

Thomas Eyde wrote re: Developer Myopia
on 10-05-2009 7:15 PM

@Akward Coder,

How did you conclude that TDD is not going to be any faster to make changes? I often work alone, and my TDD habits makes me painfully aware of how often I break my own code. If I skip that part, it will take longer before I discover my mistakes. How will that speed me up?

jdn wrote re: Developer Myopia
on 10-05-2009 9:08 PM

Unsurprisingly, I agree with this.

What is as scary as the myopia, is when the myopics talk about 'drumming people out' of the profession.

PM-SilverCrux wrote re: Developer Myopia
on 10-06-2009 2:18 AM

I think Jak has a point in a way that Methodologies are not the most important point.

But to say that Methodologies are not important is far stretched. Everyone follow a methodology to develop software. And methodologies != TDD,BDD etc. There are lot of other methodologies and every one does follow some form or the other.

It's about "which" rather then "if". YOU as a developer has to choose a methodology based on your constraints of time and budget as well as your familiarity level.

Jak Charlton wrote re: Developer Myopia
on 10-06-2009 3:43 AM

@Steve

Actually my post wasn't really a response to Scott's post, but more an attempt to put development in some perspective.

As it happens, you almost put the title of my next blog post in your comments - Good Developers Write Good Code, Instinctively

Paul Cowan wrote re: Developer Myopia
on 10-06-2009 7:06 AM

What this whole duct tape debate has said to me is that as developers we are more concerned with the internal structure of our code than the external behaviour of the products or services we produce.

When do you ever see a developer blog about usability issues of a UI app which let us face it is what a lot of us are working on.

Usability is one of the main reasons for failure.

The echo chamber is quick to insult a code base they have never seen like stackoverflow and not congratulate what is a well performing high volume website.

People seem very quick to blogboast about how they have adopted kanban, scrum, git or whatever the hell is du jour but it is all inwards facing.

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code.  It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature.  Anybody who dares challenge it is slated as unprofessional.

Awkward Coder wrote re: Developer Myopia
on 10-06-2009 8:34 AM

+1 @Paul

TDD is flawed from that respect only because developers try to use it as a measure of acceptance by\for the business - the business shouldn't even know how code quality is measured...

Thomas Eyde wrote re: Developer Myopia
on 10-06-2009 6:31 PM

@Awkward and Paul,

You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?

Paul Cowan wrote re: Developer Myopia
on 10-07-2009 3:54 AM

@thomas

You can tell I am not doing TDD without seeing any code?  That is quite a talent.

I can point you to the OSS project I am working on and you can judge for yourself and have a look at the tests:

code.google.com/.../hornget

TDD is good but it is flawed, too many things can go wrong.  We need to tighten the feedback cycle somehow.

But as ever the minute somebody dares to question it we get the usual accusations of unprofessional or in your case "You just are not doing TDD".

Why can we not debate it's worth or it's undoubted flawed nature rationally.

TDD is the best we have got right now but there is plenty of room for improvement.

Steve wrote re: Developer Myopia
on 10-07-2009 1:37 PM

@Thomas Eyde

"You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?"

Why is TDD the only way to guarentee this?  

Thomas Eyde wrote re: Developer Myopia
on 10-08-2009 5:45 AM

@steve,

I practice TDD quite successfully, which enables me to deliver fewer mistakes within the same time frame. When people say TDD is flawed, or doesn't work, that doesn't match my experience.

So I wonder, what did I miss? What do those people do to deliver fewer of their mistakes?

Thomas Eyde wrote re: Developer Myopia
on 10-08-2009 6:00 AM

@paul,

I am sorry. I put words in your mouth you never said. My mistake was that I never put "good" and "flawed" in the same sentence to describe the same thing.

Why is writing so much test code a bad thing? You keep doing it, so it must give us something?

Steve wrote re: Developer Myopia
on 10-08-2009 2:13 PM

@Thomas

While I doubt it was your intent, you did make is sound like TDD was the only way to accomplish your goals.

Does BDD to an extent also accomplish everything you want and them some?  At the very least, it promises that your code does what the customer expects it to do (something TDD does not).

I'm in no way saying TDD is bad, but this perception that people are tring to give that everything done without TDD is crap really needs to go.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)