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?
- First, the developer thinks about the problem they need to solve
- Then, they solve it (usually by writing code, not always)
- 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!
congrats, you’ve invented another name for cowboy/hero coding.
Well, as they say: “You can’t test quality into code”.
I think the real issue is that there aren’t enough good programmers and companies don’t know how to hire the ones that are out there. In addition, there’s no tradition of training programmers to become good. Instead, there’s a tradition of encouraging even the good ones to just produce more crap, ever faster. It’s a rare individual who can raise above it all and even then there’s quite an amount of risk involved in that.
Many people just rather do what they’re told than attempt to upset the status quo. The people belonging to the latter group get fired a couple of times and move into the former group. So, we have a culture of creating bad programmers. If you want good ones, you’re mostly left w/the option of trying to somehow hire a few of them, which is hard or then training good ones yourself. Few companies nowadays ever consider the latter, because of the related costs, etc.
As far as I can tell, this has been going on for decades and therefore there’s no reason to assume that it will change in the near future. It has been pushed to change for at least a decade already and there’s not much we can speak of when it comes down to having any real results.
However, if you have your own company you can try to do things a bit differently. However, it’ll never be easy, because you need to get to the market lightning fast, which always leads to horrible hacking. It’s a vicious circle and even the most well-meaning easily fall prey to the economic realities.
Effectily, making it to the market and staying there requires different approaches. Having good programmers helps a lot in all situations, I’ll give you that. But it is a catch-22 and that’s why there are no silver bullets.
Wait…
You mean I can finally unswallow the Kool-aid and admit that sometimes I just…you know…write code without inch thick forms and half a pint of blood… And the code works well… And that’s OK?!
Really?!
I feel like I’m coming out of a closet even thinking about this.
So how do you ensure that this code works in the future and that some other member of your team doesn’t come along and screw it up, or worse, yourself? By writing tests!
This blog post saddens me that some think they write flawless code. Yeah, and I shit rainbows.
I’ve got a post about this which explains my reasons for testing in a story form: http://ryanbigg.com/2010/02/congratulations/
Cowboy programming? At least that is unlikely to be outsourced and done by indians.
There is a difference between recognizing and being able to play music and being able to compose music.
Like C++ and OOD, the means becomes the end. Fragment. Obfuscate, oh, I mean Abstract. Who cares if the design is atrocious and chaotic as long as the right members are made private, protected, or public, and that instead of saying A=B, you say SetValueOfA(GetValueOfB());
Good programmers can write emacs LISP macros that are more understandable (“elegant”) than someone who is not good following any process in any language.
So, i agree.
I guess that the only problem is to change like people think about XDD tools, following this it’s a big problem to be solved.
In fact, don’t matter to follow the steps “How does it work?”, ’cause crappy programmers can’t do this. Du’hhh
nice article ;p
@avdi Cowboy coding is when “programmers” of dubious skill level write code without any thought for design or quality. Totally different than smart people carefully and thoughtfully choosing the right tool for the job, irrespective of trendy buzzwords.
@Ryan Which part did I say testing wasn’t valuable? First of all, automated testing is not the same thing as TDD, but I don’t even have a problem with doing TDD. What I do have a problem with is all the “radical” new approaches to programming with shiny new buzzwords that think they can solve the problem of crappy programmers with business-speak.
A good developer may very well choose to write automated tests and/or practice TDD, but just because your company does these things doesn’t mean your code quality is any good. I’d take buzzword-free code from a great programmer over “best practices” code from a crappy team any day.
They aren’t radical. They are what should be the standard. TDD/BDD have proven themselves time and time again.
You think through the implementation, write the tests for the implementation, implement it and then refactor it. The tests are there to ensure that it’s *always* functioning and to not write tests *at all* is plain ol’ fashion suicide.
I know this first hand. I was a bad developer. I may still even be a bad developer, but at least now I’m writing tests so people can understand what the code *should* be doing and then go about fixing up any horribleness I’ve left around.
@Ryan Bigg
You said it man. I’ve been from coding to designing to management and back again. I never appreciated the power of uniform testing until management however. Anyone can write elegant patterns, no one can write error free code. Also, if you code as I do, you are testing over and over every time you change any logic.. but the cumulative tests fail, why??? because of the cascade effect. The ONLY solution is to write tests. Whatever the language, framework or no framework. It’s like a prophylactic, the benefit of abcense might be more convenient but the risk outweigh the reward exponentially. First time, every time!
Hilarious, you sound almost as jaded as I. Deadly accurate of course, it really is that simple. Too bad the programming industry is 99% b.s. It’s getting harder to find jobs solving actual problems as opposed to the self created ones. But companies need to be able to point to a ‘process’ so they can sound like they know what they are doing, and make developers interchangeable cogs. If they can put the intelligence in the ’system’, they can take away reliance on *good people*. They can’t of course, but fail to realize this, and so the game goes on. Besides, people/companies/’experts’ want to sell frameworks, support services, tools, enterprise servers, ‘middleware’, training seminars, etc. Hell the whole industry would collapse if people did their actual jobs. The problem must be created for the peddling of the cure. Delighted to see at least one other person spots the naked emporer…
Wow, does this mean all the Indian programmers are going to have to go back to selling carpets?
There’s just D. Developers. They may or may not write code that works. Actually, they’ll probably be able to write code that works today or for the next few weeks/months. Shoot, it might even work for decades!
The real test is whether or not it’s easily maintainable. That’s really what we’re saying when complaining about “bad programmers”. There’s a lot of really nasty untested code out there that works and makes money. I know because I work with such a codebase right now.
The real issue is whether or not you can confidently make changes and not be afraid if things are breaking. TDD/BDD are one way to get there. But like others said, it’s really up to the people. And people with the right attitude can sometimes write terrible code while they’re learning. Take it from me. : )
Anyway, I guess there’s not much of a point here, just trying to say. There’s only Developers. All we have is XXD.
[...] From the article: [...]
In this world, % of dumb people outnumber smart ones. Hence, in all engineering fields, there are processes to ensure that a minimum level of quality is maintained. TDD is that thing in software.
[...] Introducing Developer Driven Development (DDD) | Code Anthem [...]
Processes and XDD are the only way that good programmers can reliably hope to teach others the art. You might take code from a “skilled” team over that of a team not as skilled but that follows a process. Assuming equal amounts of initiative though, who would you rather have in the long run?
In any non-trivial setting, our job as good coders isn’t only to write great software, but also to ensure that we help build great coders. Processes are key to that.
You’re definitely right that writing tests doesn’t guarantee that your code is any good. But at least it makes your intentions obvious and provides some baseline level of insurance. And yes, you can certainly write “good” code without doing TDD/BDD, but rarely will it ever be maintainable.
The problem is that you’ll eventually wrap this project or feature up and move on to something else. Months pass, and then yourself, or god forbid, some other poor soul, will have to pick it up and iterate on it. Suddenly your “good” code won’t seem so good. The intentions of a developer, no matter how obvious you think the method names and comments are now, isn’t always clear to someone else. Or even to yourself in hindsight. Your skills will evolve, you’ll get better at what you do, new tools and best practices will come to light, and what you wrote a year ago will seem primitive and crappy.
Tests are insurance that keep you from introducing unintentional regressions and ultimately save you time. Are there situations in which you shouldn’t write a test? In which it’s maybe more trouble than it’s worth? Absolutely. I’m not a purist. I’m not arguing for 100% coverage. But even if you honestly think you’re omnipresent or you don’t think anyone else is ever going to touch it other than yourself, you are going to introduce regressions from time to time unless you have the appropriate level of coverage. You’re going to curse yourself when you do this, and waste at least as much time as you would have writing the tests in the first place.
You don’t write tests and this has never happened to you? I don’t believe that
.
As someone who was a contract developer and ran small web firms for 5 years, there was nothing I hated more than being brought on to rescue or iterate on a project that didn’t have any testing in place. Think of the children!
What @nap said is spot on. If this technique is as a good as you submit, I would invite you to develop projects for 2-3 years using the technique with multiple teams, document how it lends itself to productivity, maintanability, to the evolution of dynamic and changing requirements and how it delivers success to the business.
If you manage to show the above, then you’d have a hit software development process which would get people’s attention the world over, you’d have speaking gigs at conferences on the subject and would challenge the status quo with your hard evidence.
If you’d also shed some light on where you find such a stock of good programmers as required, then we’d also be grateful.
@nap TDD is not the same as automated regression testing. So I agree with your arguments, but this post was more of a parody of developers jumping on the latest bandwagon (aspect oriented programming, feature driven development, etc)
@jp Sorry, but it was just a parody ….
@Amber: you should at least read up on your terminology before debating methodologies. From the original WikiWiki (http://c2.com/cgi/wiki?CowboyCoder)
Cowboy coding works fine when you are a solo developer working on a short-lived project. It breaks down when you have to work on a team and be responsible for the codebase for greater than six months. You can either learn this from the experiences of others, or you can learn it by your own experience; but the former will save you time, frustration, and possibly save you from being the cause of a failed project.
Wow! My current employer has so many “processes” and they’re all because those on the teams are crap at their job, and the processes force them to atleast attempt to be productive…. Man! And I totally agree there’s a huge risk to “rocking the boat” and trying to suggest efficiency and quality instead of dying in the process sink hole.
And yeah, all the “_DD” coding practices are sadly used more for trying to limit the damage of bad programmers then taking full advantage of good programmers.
Though I laughed at the cowboy and indian reference, (Thanks TZ) I’ve seen more issues with cowboy programming then benefits. Avdi was right. Cowboy = GREAT for short lived/solo, and can be an effective tool for “proof of concept” coding, but group coding environments aren’t the place for cowboys.
I’ve seen a lot of comments here defending *DD processes and rightfully so but I’ve seen very little agreement that software quality starts with competent developers and not a process or framework. Frankly, I find this quite disturbing. If you’ve done this you are missing the point.
FWIW: I’d much rather have a good programmer write untested but clean code, than a bad programmer write tested but messy code.
The good programmer will likely find ways to make the program simple and the program will communicate it’s intent to some level.
The bad programmer will make a big mess no matter how much testing is done on the code. And the design and architecture will be difficult to improve.
Of course a good program with good tests is even better.
You might argue that bad code with tests can be refactored into good code using the tests as a safety net. In my experience that is rarely the case though as the bad programmer didn’t think through the interface of the classes he was building, so he ends up testing the ins and outs of the class instead of just the public interface leading to a situation, where you can’t refactor anything without rewriting a whole bunch of tests – and then the safety net is no longer a safety net.
@terry — I think it’s safe to say that that’s implicit in any argument about *DD. “Don’t hire incompetent” developers shouldn’t have to be spelled out, should it? Anyone who is stepping up to champion test-driven best practices is obviously already a practitioner who cares about the quality of their work and the work of others. :p
@Terry you hit the nail on the head.
@nap I can only assume you haven’t been around the block, if having great developers is an obvious prerequisite to you. Consider yourself lucky, but there are plenty of mediocre shops churning out horrendous code using “best practices”.
Better if we use DeDD (Developer Driven Development) or CaOP (Cannabis Oriented Programming)??
@Amber Wow, heh. Maybe it’s that or… maybe I just choose to work and associate myself with people who do good work
. If you’re the type of person who takes a position with a company or associates with others who do shitty work and you know it’s shitty, get the hell out of there. If you’re not working with other developers you respect and can learn from, you’re wasting your talents and fighting an uphill battle.
You’re right of course that there are people out there who do shitty work but who claim they’re embracing “best practices” to do it. But those people don’t get it. They’re appropriating a tool as a marketing term to sell services rather than really understanding the benefit of the technique and putting it to work. That’s not a failure of xDD, that’s just a shitty developer doing shitty work and saying what they need to say to make bank. Don’t confuse the two.
@nap Dont confuse your own ignorance for elitism. People doing shoddy work with a fancy label is a plague on the software development industry, whether or not you know or care. It’s easy to be dismissive, not so easy to work for change.
@Amber
How does “Developer Driven Design” actually influence your stance at all?
Let’s say for a second you’re using “Developer Driven Design”, so you think about good code and then write it. Cool. And you’re on a team with crappy developers who think as hard as they can, but pump out completely crappy code. What now?
How is that any different than if I work with TDD, or any xDD for that matter, and end up on a team with a bunch of crappy developers who “use TDD” but have no idea how to do it properly or why they’re even doing it?
Either way we’re better off leaving that team and finding greener pastures.
As for the “plague”, who cares? Let them compete in open market. Their crappy work will lose them customers, and your quality work will earn you customers. They’re just driving business for you by showing customers what to avoid – buzzwords without clear understanding.
[...] Cowboy coding via DDD [...]
@Ryan Bigg and others:
if your code have cascading effect problems, then you indeed are a bad developer.
I’m on the wrong side, that’s to say, I reckon that I write way to few tests; but that’s mostly because all the code is usually tested on spot: all the corner cases, race conditions, library access, everything that could fail for any reason is tested right there _in_ the code. And the code itself degrade gracefully
how many of those corporatish written TDD application fail with an exception if a configuration file is not properly installed, maybe because a written permission was not tested during installation and not checked within the code?
that is something that *proper* coding discipline doesn’t allow to happen.
there is no way a proper coded method would leave the application in an improper status. you’ll really need to learn to write stuff that works _or_ fail with a trace message and a proper notification. then you’ll have no cascading bugs and test will become so trivial that you can incorporate them in your code
Hi, Amber.
It’s a late comment, a few weeks after you wrote the article.
I fully agree with the idea of better programmers vs. process.
One only need to look at the most awesome and hilarious contrast between Peter Norvig (strong programmer) and Ron Jeffries (strong process salesman) and their approaches to solving Sudoku.
Norvig’s code actually solves the problem. Jeffries’ code fulfills the need for process.