Development Driven Development (DDD) is a revolutionary new approach to development that focuses on … you guessed it, development! DDD takes a radical approach in an industry filled with tests, metrics, and processes by allowing smart developers to write code. Some managers and even developers have a hard time wrapping their heads around it conceptually because it does require a shift from existing thinking.

How does it work?

1. First, the developer thinks about the problem they need to solve
2. Then, they solve it (usually by writing code, not always)
3. Repeat until done

DDD vs TDD vs BDD vs FDD vs ADD vs …

There are people out there writing code who really shouldn’t be.  They produce bad code and crappy software.

The obvious (and correct) solution to this problem is to only use bright, thoughtful programmers.

Instead, the software community reacted by putting in place safeguards and frameworks and processes.

Since the more thoughtful programmers tended to be the early adopters, the code that was produced was better, and the frameworks appeared to be a success.  Now all we have to do is get more people to use the framework, and the code will just get that much better.  This is similar to selling diet drinks to gym trainers and noting that they do, in fact, lose weight and look great.

In reality, crappy programmers will always find a way to produce crappy code, even if they are using XDD.

But I am a good programmer and I want to use XDD!

Good programmers will write good code regardless of whether or not they use TDD or not.  Certainly, these tools can be helpful and there’s nothing inherently wrong in using them.  It becomes ridiculous when people start to think that this tool that may be useful to some is going to save us all from bad code and crappy software.  Or that a smart, productive developer who does not use XDD must be a bad developer.

Frameworks and processes don’t build good software, people do!

How do you know if you’re software project is going to crash and burn?  Use these handy tips.  Consider it a reverse Joel Test.

1. It started out with Waterfall and then once they completely derailed and went into a free-fall, started calling it “Agile-ish”.  This is also known as fake agile, or “fragile”.
2. Fixing a bug always exposes another bug. If the software is so buggy that you cannot even GET to certain parts of it due to the bugs, then fixing one just exposes another one, and another one, and another one. This is not the same as causing a bug with your bug fixes, although that’s not good either.
3. One or more of the central technologies became unsupported by the manufacturer before the project even started. Even better if the technology line has been discontinued entirely.
4. You’re using PowerBuilder or any other “rapid development tool” that abstracts away actual code in favor or checkboxes and drop-downs. Libraries, toolkits and APIs are all fine. These tools are like playing Twister with code.
5. The technical lead cannot correctly use his email client or browser. If someone cannot even use basic, standard software, how can he properly lead a team of programmers?
6. The Project Manager is writing code and a developer is managing the schedule. Seen more often than I’d care to admit.
7. There are more business or domain people on a team than actual technical folk. 1 programmer with high turnover + large code base + critical system + huge bug list = no problem?
8. There is a test suite from a previous programmer but half of the tests are failing or don’t compile. For extra fun, check if reported bugs would have been prevented if the test suite had been used.
9. The process for adding a single line of code requires multiple lines of commentary. A comment at the line stating the reason and your name.  A comment at the top of the file putting your name and update date.  A per-file commit with descriptive message.  Update to the bug-tracking/PM software.  Etc, etc.
10. The phrase “it’s not a bug, it’s a feature” applies to most of the “features” in the product. “The system wasn’t designed for that.”

Have any other signs from the trenches?

Businesspeople have two distinct roles in software building:

1. To determine how software should look and behave as a user
2. To prioritize the feature/bug fix list based on business priorities

By businesspeople, I mean the customer, the client, the program manager, the product owner, project manager, client liason, customer proxy or any non-technical and non-design person involved in a software project. Ideally this should not just be a guessing game, but based on their relationship with the customer, including feedback and user testing, as well as market research, etc.

If they do any less than this, then your software project will end up somewhere totally useless, even if it technically works.

If they do any more than this, then your software project will end up totally useless and will not work well technically either.

That’s the function of a businessperson on a software project.

There’s no sense in being precise when you don’t even know what you’re talking about – John von Neumann

Instead, most business people try to stick their noses where they don’t belong. Dictating technical and design decisions based on their qualification of, you know, having used MS Office before. They also try to manage software projects as if we were building a bridge instead of software, and as if we were low-skilled, replaceable cogs in a machine, instead of highly-skilled, professional craftsmen.

The result? Ugly, broken software.

Dr. Spaceman from 30 Rock

Would you, could you, to a doctor?

It’s like me trying to tell a surgeon how he should be performing surgery based on, you know, having body parts.  No, I don’t think we need those extra sutures.  Oh, you should be using the 1/5″ scalpel instead of the 1/8″.

Nevermind that he is a well-trained, highly skilled professional who has done this before.  By employing him to do work for you, you clearly not only have the right to dictate how he does his job, but also clearly know better than him.

Of course, any decent doctor would NOT comply, and probably has an ethical obligation not to do so.  Software development professionals should behave the same way.

What’s a highly-skilled professional to do?

The crux of the problem is that even though we know the right way to build software, most of the people who employ us don’t know it.

One solution would be to go work for a company that is run by technical people.  Apple and Google are the big examples, but there’s plenty of smaller fish out there.

Or you can find a position in a team with a strong technical leader.  The company may have a lot of BS, but a strong technical manager can shield his/her team from it and give them the freedom to build great software.

Both of those are great options, but to truly solve the problem wherever you are, it’s going to take education.  It’s not a particularly sexy idea, but it’s at the heart of every movement.  We can either sit around and whine that they don’t get it, or we can make it better.

Businesspeople just don’t know what they don’t know.

If we intend to work together (and it really seems inevitable, doesn’t it?) I submit that we need to help them understand what it would take to build great software.  As in, please do the two things outlined at the top of this post, and do them well.  And for everything else, please let us do what we came here to do: build great software.

The software industry is sinking. Software projects fail at a ridiculously high rate.  Software developers are miserable in their cubicles .  Companies are applying more and more duct tape in vain.  Something’s gotta give.

In a 2009 industry study of software projects, 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are canceled prior to completion or delivered and never used.  24% of software projects, which represents billions of dollars and thousands of hours of time, were scrapped completely.

If the recent financial crises have taught us anything, it’s that the software industry is neither too big nor too important to fail.

Business are putting more pressure on ill-equipped development teams to deliver software full steam ahead.  Meanwhile, developers are being weighed down by company-imposed anchors.

Development gets delayed by endless meetings where people drone on and on.  Then there are more meetings where we all discuss why development is delayed.  And no one is really interested in building good, useful software.  Is this what you signed up for?

Does fun development really need to only happen on the side?  On open source projects, or moonlighting projects?

With so very many smart people on the job, how did we let this gloom and doom scenario happen?

Our first mistake was to ever let non-technical people manage software projects.

Our second mistake was to let non-technical people manage the hiring of technical people.

We need a coder revolution. A grassroots movement to put smart technical people at the head of software projects and to fill up the team with other smart technical people.

This is a call to arms to all of my skilled and productive developers.  Developers who have passion for their craft and are willing to fight to make it better.

We’ve waited a long time for the big companies to come to their senses, but it’s not going to happen.  Those bloated corporations are too large to see their own feet, much less walk around.  And the smaller companies who should know better are just angling to be a big bloated corporation.

We have to make this happen ourselves.

• Business jargon and marketing speak only impede successful software building.  Let’s cut it out.
• Clueless non-technical managers have no idea what it takes to build great software.  Let’s do it ourselves.
• Buzzword-riddled resumes are a preposterous way to identify skilled developers.  Let’s find a better way.
• Recruiters don’t add any value to the hiring process for computer programmers.  Let’s go direct.
• Talking about building software does not indicate any technical ability.  Let’s show what we can do.

One day there was a team of rowers who wanted to go out on their own. They started looking for a boat to rent, and came across one for a great price called the Good Boat. It didn’t look as nice or seem as big as the boats that the other rowers had, but the boat-maker assured them that the construction was high-quality and that they wouldn’t have any problems. And just to be sure, he was willing to join their team as their in-house Professional Boat Fixer.

They began their rowing journey and a little while later, the hull had a small leak. The Professional Boat Fixer sprang to action, applying all sorts of complicated looking patches. He worked long hours and was happy to regale anyone who would listen with the complexities of his solutions, so no one could complain. After awhile, the patch broke and another leak sprang up somewhere else, so the Professional Boat Fixer became very busy, fixing the fixes and new problems. He even hired Assistant Boat Fixers to work under him and help him apply his patches under his close supervision.

The rowers decided the wanted some new benches to sit on and some other items that the Professional Boat Fixer refused to create. So they found themselves a New Professional Boat Fixer to work in tandem with the Old Professional Boat Fixer, to be in charge Things the Old Professional Boat Fixer Will Not Do. The New Professional Boat Fixer was shocked to see the horrible state that the Good Boat was in. The New Professional Boat Fixer exclaimed, ‘I can fix that!’ The captain and other rowers were interested at first (not realizing they had such a problem) but the Old Professional Boat Fixer firmly explained that there was NO problem with the Good Boat or his fixes, and also, the furniture was all shoddy and the New Professional Boat Fixer was not to be trusted. Unable to continue to work on a sinking ship, the New Professional Boat Fixer left the boat, to be replaced by a string of Newer New Professional Boat Fixers. All of them tried to fix the state of the Good Boat, but they were bad boat-fixers and not to be trusted, or so said the Old Professional Boat Fixer.

At some point, the Old Professional Boat Fixer was promoted to oversee the rowers, in addition to the Assistant Boat Fixers. After all, there was a complex system of rowing required to keep the boat going straight (it naturally veered all over the place, in no predictable pattern), so it only make sense that he should oversee them.

To this day, the Good Boat is still chugging around the ocean, slow and not-so-steady. The Old Professional Boat Fixer and the Rowers are considering creating more Good Boats together, with the Old Professional Boat Fixer as the Overlord Good Boat Master. The Good Boat is considered a myth by some Professional Boat Fixers, but I have seen it with my own eyes and share this story as a cautionary tale.

Images by danslegrandbleu, law_keven, and rene_ehrhardt.