If you look at most articles today on the discussion of development or design methodologies, it seems programming is more of a form of art than engineering. I think the Agile movement sums it up pretty well. Most people don’t even know the principles of Agile development, but usually, reduce it to “I don’t have to do any documentation or planning”.
This brings me to TDD. I haven’t been developing for a long time, but in my short career, I’ve never seen anyone turn their nose up more at a development methodology than TDD.
“It’s impractical”, “It takes too much time”, “not everything has to be 100% working”, “It’s a plague set on development community by academics to ruin any fun us devs can have”.
Naturally, I’m paraphrasing and sure, to a certain extent, there are some things learned through actively coding that you can’t learn through rules. But you only really learn more when you try to follow these rules and guidelines, push them to their limits and decide for yourself if it will work for your project and team.
Thus follows my arguments for TDD and what I’ve learned from practising it, as strictly as I could, for the past five months. This article assumes you already understand the basic concepts of TDD and the 3 Laws of TDD. If you haven’t, here are a few articles to give you some context:
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
“It takes too much time.”
Sure it takes longer, but doesn’t anything worthwhile? Planning takes longer; understanding requirements takes longer; proper research takes longer; a PhD takes longer. The real discussion that needs to be had is “Do the costs outweigh the benefits”?
I think it does. What it boils down to is that writing tests first and only writing code that can make tests pass is a way of reducing any side effects of code to the point where the only bugs that can appear are resulting from your misunderstanding of the requirements. If done correctly, tests altogether remove unintentional bugs or side effects brought on by the moving parts of a system.
If you look at enormous systems for banking, medical care and education - I’d say they have enough influence on the lives of other people that you have to make sure that all the possible precautions have been made to reduce errors. I don’t see why the benefits don’t outweigh the costs here.
“It’s not ‘real world.’ ”
I don’t know how to give this argument a polite answer, so I’ll be frank: This is a dumb argument. There’s no such thing as an “unrealistic approach”. It’s all up to the client, and the client doesn’t know any better. You have to convince the client that the approach is necessary and useful and worth the extra time investment. The results of that argument determine the plausibility of the approach.
The problem here is that the people who make this argument haven’t tried TDD, and if they have, they didn’t commit to it. And I’ll be the first to say, and it’s not fun. It draws out writing simple pieces of code and has a steep learning curve, but at the end of the day - it’s not supposed to be easy.
Above all else, the problem is that developers just don’t care. Everyone just wants to get paid and go home. Which is ironic, since not taking precautions like these will actually make maintaining a system a lot more stressful in the long run. In any effect, this culture of wishy-washy development practices will probably continue for a while - software development hasn’t had enough time to mature like engineering and the sciences.
“It doesn’t have to be working 100%.”
Beg your pardon? Can a plane fly without the guarantee that it’s landing gear will work? Are life support machines used under the assumption that they might occasionally fail every few days? Do elevators have high enough failure rates for getting stuck in one to be a regular occurrence?
No?
Then why is the same not true for software? Like I’ve mentioned before, many systems that run everyday society, are written by us. Even the ones that don’t seem so crucial or life-altering, probably are.
In economics, we can’t predict the changes in markets or when the next recession will hit. That’s because every economy is built on the trade between its participants. Tiny interactions that happen at such a frequency and scale that it’s impossible to comprehend with a few simple calculations. The same goes for the users of your system.
Let’s illustrate this with a simple example. Say you write a dating app, innocent enough, right? You launch your app, and all the major features seem to be working, you’re getting positive feedback from your users - all in all, it looks like a success. But uh-oh, look at this, your reporting feature doesn’t work. One user starts abusing the app to harass women sexually, but every time they’re reported - it doesn’t reflect in the system. Now, the users expect that their harassment report has gone through and go on with their day, the employees responsible for handling harassment reports don’t see their reports reflecting in the system - so they assume all is well. Now you have possible sex offenders running rampant on your dating app.
You can even reduce it down to; you’re just writing bad software. If you write bad software for clients and their competitor’s are better, your clients will probably fail. You could cause serious monetary damages to businesses, and these businesses have employees like you and me to pay.
Developers are so separated by consequences of their actions that it’s no surprise this is the case. I’ve heard developers complain about just about every problem that a solution exists for, only they don’t want to hear what the solutions are - because they’re brought forward by silly academics—speaking of academics.
“Academics don’t know anything, and they just sit in their armchairs all day, smoking a pipe and thinking up rules for me to follow.”
I mean I’m not too fond of academics either, they are pretty annoying. But the people coming up with these methodologies, approaches, principles and paradigms aren’t academics. They’re developers and software engineers, and they have the merit to back their claims. Kent Beck, the man who turned approaches to software development into what they are today, with his book Extreme Programming Explained, works at Facebook. Do you think Facebook hired some random oaf to make sure their system is working?
People like Robert C. Martin, who popularised SOLID principles, has worked as a developer his whole life, starting from the age of 18. And he’s 67 now! He witnessed and wrote some of the earliest forms of software, back when they were still using punched cards. Do you think he knows nothing?
The idea that you know the correct approach to programming when you only have a few years experience is baffling to me. Sure I only have a few years experience, but that’s why I refer to the experts. You might not even notice the mistakes you’re making now, and it might take you years to realise them.
That’s why I listen to the people who already have.
References:
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
https://en.wikipedia.org/wiki/Kent_Beck
https://en.wikipedia.org/wiki/Extreme_programming#Origins
Published By: Duen Oosthuizen