When I discovered Clean Code, design patterns, TDD and BDD. It just clicked. Ever since everything build so easy and obviously. I no longer have most of the code problems folks rant here about.

That's when it came to me: it's not enough to know how to write code. To climb off those amateur shoes I must adopt those methodologies, so that the code would be decoupled from me, from my style, and I've got to let tests drive my code rather than vice versa to have a flexible and reliable codebase that is cheap and easy to maintain/extend.

Yeah TDD is an epiphany

@cypher looking for reasons not to learn tdd?

Btw bdd adresses post author's concerns. That's why I'm combining them.

Do you think TDD is not something people get excited about since we are addicted to solving bugs?

I mean I get a super high after I fond the solution to one.

@netikras nope, I'm just giving another point of view.

One year ago I was diagnosed with terminal brain cancer. I went through all the standard treatments but the cancer only got worse. When I the doctor told me I had two weeks to live I had given up all hope. That's when I stumbled upon "The enterprise methodology and design pattern Koran." At first I was sceptical but after just two days of implementing DDD, BDD, TDD and anything else the comes in a Double Dose my cancer had gone into remission. After one month of enterprise software engineering I have become a billionaire, had seven children, married a beautiful woman, aged five years back, my pot belly has been replaced with a six pack and I've even grown a few inches longer. I can't stress enough the benefits of these life saving methodologies.

@RANTSMCPANTS eh?

@cypher tdd isn't just writing tests first. Probably you've heard this before: it's not about testing, it's about development. Like @netikras said, it is better to talk about bdd. The tests are just the specs, the requirements, hardened in test form. Tests come after the requirements are discussed. It helps towards keeping the code modular as well, imo.

@netikras I liked your satirical post so I complemented it with some more satire.

@RANTSMCPANTS it was not satirical :) I meant every word in there

@netikras The thing is, what you're advocating doesn't pan out in reality. Sure, if you have a fire and water seemed to work well enough for you then you might spread its merits but wait until you have an electrical or chemical fire. I've seen projects killed because people are trying to put themselves high in the sky trying out things such as TDD, DDD, etc rather than just being able to code.

You can't do away with the individual and become TDD. I get the concept, I apply it to sysadmin, I live off the land, when I go into a system I'm not rants, I'm root, we're all root, I don't personalise it.

That concept doesn't universally apply and I think it doesn't apply here either as much as you might think. While you're "abandoning" your code style, you are replacing it with another, TDD, etc and I think that's probably more about you and your circumstances than you might realise.

The point you get things like TDD is when you can say it's bad, unless...

@RANTSMCPANTS It's funny, because you are not the first person who claims TDD/DDD/BDD does not work in many cases. Though not a single person could give me particular examples where and why these methods would not work.

Could you? I'm truly curious about it.

@netikras If a programmer is good, they can technically speaking make do even with the worst of circumstances, so if DDD, TDD, etc aren't well suited to the problem, they'll do something good with it still but then probably leave eventually.

What you don't necessarily consider is that most programmers are not the 1337sauce like me, I suck, and I'm still a jedi master. I've tried hiring truly fluent coders and it's really hard.

These things all end up adding work and overwhelming the average programmer who is likely not fluent.

You see people implementing stuff and asking what it is. It's DDD, it's not that feature you asked for. These concepts are abstract and difficult to know how or where to apply without broad understanding. For many fluent programmers they're mostly overhead and for new programmers they're overwhelming.

Some aspects of these concepts make them *feel* like it's easier but when you objectively measure, nope.

@RANTSMCPANTS
I completely agree that these concepts are overwhelming for new programmers. But have you seen how they code? Like headless chickens! Writing code, looots of code, oh soo many lines of code and eventually they turn out to have written a buggy solution to some other problem than they were asked to. Time is wasted, energy is wasted, the junior is happy because he wrote lots of code.
t/b/ddd concentrates developer's focus on the problem he/she is to solve and nothing else. Yeah, it's annoying, because it interrupts your flow and it makes you commit to the end result. But that is the essence of our job -- to commit to the end result! Not to the process.

As for fluent ones -- allright I haven't seen THAT many programmers, but taking projects after the ones I have seen - it's sometimes a pain to maintain that codebase. It's been built quickly, yes. But it's also been made rigid, far from 'O' in SOLID. TDD does solve that problem very nicely.

@netikras If we break it down, we're translating A to Z. DDD and BDD are attempts to make some kind of unbreakable chain of translation from A to Z adding unnecessary tranformation frames (every letter of the alphabet). I can take requirements and specification then directly translate them to code. I don't need a giant Rosetta machine, it's overhead in most cases. There are lots of pockets for those but it doesn't work as a uniform. Wearing nothing but a mankini works great at gay pride, not that I'm gay but I love wearing nothing but a mankini. Wear it to work though and it's not appropriate. These methodologies are the same, even if you learn to do them properly, they only objectively achieve gains in niches, not in common. People "feel" like it makes more sense because of the line of english per line of code but remember the rosetta stone was three times the size as a result. If you just hire someone that knows English and code, the job's already done.

@RANTSMCPANTS I mean... Considering fluent ones ir probably depends on what are you focusing on. On how fast can the dev BUILD the thing? Then yes, TDD will be a parking brake for him, slowing him down tremendously. BDD -- I somehow doubt it. (Could you elaborate on how BDD and DDD slow down the fluent ones? I might be missing smth obvious)

But it's a very short-sighted PoV IMO. This strategy is only suitable for throwaway projects which are not meant to be maintained or extended in the future. I am speaking as the one who used to be dragged behind the fluent ones and trying to maintain their codebase, while the fluent ones were sent off to build something new. Quickly.

I'm open for a discussion.

@netikras Not that I would mind if a mankini became the standard at work event though it's not appropriate, it's been known to happen.

BDD and DDD try to make it like your code can be read by the customer to confirm it meets requirements and in reality that rarely pans out, it's like formal methods. It's a huge investment with limited gains unless the domain lends well to that (IE it's probably easier for simple isolated cases).

TDD again is similar, trying to make everything segue down into the code. There are useful modes of thinking like to devise tests early as part of the specification for acceptance but they don't have to be programmatic and they don't need to all be done before code in a strict sense. Otherwise you prohibit being able to prototype or just seeing how something works out or being able to do something that's at least 75% of the way there.

@netikras TDD, DDD, BDD, etc are nice to know about and have in mind, if you make them mandatory though or be a part of peer pressure, what you get is people developing those because they feel they have to.

Non-fluent coders can't code very well, those things make them feel good because it is evasive of code, it tries to map code to English, it's like a substitute for a bad language teacher. Same for a lot of patterns that are popular. People see things in plain English and feel comfortable. People need to go outside their comfort zone to learn to code fluently.

TDD, DDD, BDD all massively increase the amount of code needed. If someone is learning I want them to do nothing other than get one thing to work. They're struggling with a hundred lines. I'm not going to throw another thousand lines on them.

I see things like people trying to do TDD, I fix the code, load it or run it to see it works, then all the unit tests break, suddenly another day of work. rm -Rf tests

@RANTSMCPANTS while BDD is originally meant for a business person to be readable, it does not mean it must be this way. I can easily wite a JUnit test at a high layer to act as a behaviour description that demands for a working implementation. It's not a unit test per-se, It's not a Cucumber test as well, but it has the very similar structure to Cucumber and it tests a behaviour.. And it still fits the bill -- it describes the desired behaviour of the feature/module that MUST be working at the end of the implementation. Write similar tests for different use cases (i.e. copy-paste them from BA's Confluence page and rewrite as JUnit tests) and you have a suite of tests assuring you will build exactly what the client has asked for. And you will be certain when you are finished.

@netikras I get it's intention, in theory it's very good but in the real world, the business person never reads the code and one way or another things eventually will go wrong and they'll lose trust.

I've never ever seen a business person actually engage in this process. They like it because you're doing something with them in mind but business people are business people, they really don't want to get into the nitty gritty, even if you think you made it easy for them.

There are niches where programmers are not and cannot be the domain expert, things are tricky, stakes are high or fit into that well but they're not the standard.

You'll find, ultimately, people just want the thing they asked for and the less involved they have to be in that so they can get back to business the better.

It's actually a big engineering mistake to go into the how too much. Just tell them you'll do it how google does it, something not even google knows so can't be proven wrong and you'll be fine.

@RANTSMCPANTS yeah, that's the massive drawback of TDD :) If you are testing each unit, then any refactoring of prod code also requires tests to be rewritten.

But BDD does not have this problem.. And applying TDD at points which are mission-critical is also not that much of an overhead. I mean it's pointless to use TDD for basic components or data structures or things like web controllers or DAOs. But core services, core aspects, auth, core components that are to be used and reused in lots of other places/projects.. I believe these should be built with extra care, in a truly reusable manner. And tests-first does guarantee those components to be flexible and stable.

Do you reckon I'm wrong?

@RANTSMCPANTS umm.. I'm not saying business people should be involved in code... IMO business should be kept as far away from the code as possible. A very high level architecture - maybe. Basic technologies (even better -- buzzwords seen in news portals) -- absolutely yes. But introducing them into code, services, components, tests,.... Why?

IMO all the tests written are only meant for the developer and maybe QA. That's all. And a test built in a BDD manner serves this purpose very well. It keeps the dev on the right track and raises red flags when the dev is risking to break the product (and lose client's trust, cause financial and reputational damage, etc, etc.). W/o the right test suite it's very easy to break things. W/o the right test suite it's also very easy to build Y while the client wants X.

I don't mean to sound like a broken record, sorry if I do. I'm just trying to express my reasoning.

I am liking this discussion.

As a person who has faced great resistance to bdd at my workplace, I feel like contributing here.

At my place, managers like the outcome of bdd. To their silly minds, cucumber suite is a low effort measure of progress and ensures good code coverage.
The initial setup cost is high and it's difficult to do it, initially. More so if you're working with rigid legacy apps (like I am).
To be able to define bdd unit tests, you need your codebase to allow it. If you can't mock objects, you can't unit test.
Then there's the training part. In usual work flow, project manager distributes requirements to devs, they figure out what to do based on what they understand and their experience. If you're practicing agile, you'll know by the end of sprint what to change. Is that a problem? Maybe if you're the dev and have to redo things. Not so much if you're the manager. Bdd involves more steps and adds responsibility on the manager (or any stakeholder too). (1/2)

(2/2)
However if you take time to train everyone and setup the infrastructure for practising bdd, then I feel most of the overwhelming parts will be taken care of. It becomes a process and people are quick to familiarise themselves with company/team processes provided they are implemented in a top down way.

In my case, after the manager distributes tasks, we have weekly meetings to discuss requirements, progress and issues. We're already discussing specs. With little training, everyone can speak the language of example mapping and make discussions more productive. (Right now our meetings are mind numbing wastes of time. 5 minutes of actual content in an hour long meeting.)

Without good tool support it's a fallacy to blame bdd for slowing the developer down. I find it is a more natural process than coding right away and then worrying about quality later on.
It could be a great strategy for maintenance when you start new projects. However, legacy code remains a challenge.

@dr-ant The problem is with BDD, DDD, TDD, etc, if it works for you and your current situation, great but don't assume it's universal and especially don't assume whether or not it works is a matter of applying it right, it's so much more knowing when to apply it.

Someone said no one has told you where it doesn't work out. You already have the information you need. If you truly understand it, *you* should be able to front that. Every argument I've had I seek to make the other person's argument for them. If I can't then I haven't mastered the concept. If I had I would be able to dance around both sides and fence with myself as well as with anyone else.

People keep making this argument it's just a matter of getting used to it, well yes if I were being tortured every day in captivity I wouldn't have much choice.

When people are resistant that's often for a reason. You're trying to impose your will on them. Who are you to immediately presume yourself to know better than them?

@dr-ant This is also a manipulation.

You make things ten times hard by introducing both new and unnecessary things.

Then you make it half as hard giving relief when they get used to it, but it's still five times more work for the same result than as before.

It's like walking up to someone and furiously punching them in the face ten times a second then slowing to one time a second then touting your success about how happy they were.

I have to work in psychology and how to manipulate customers to buy shitty stuff or failing that if doing things on the up and up knowing what our competitors are doing so I am very well versed in these techniques.

@RANTSMCPANTS Wait what are you even saying. I want everyone to have the disadvantage of doing TDD, DDD, BDD?

Then it means for the companies I do stuff with I have the competitive edge of not having all that overhead.

The more laborious the simplest thing is for others compared to me the better. As long as I don't practice what I preach I should be practising all these added extras that make people think they're getting more value but are really just more costs.

I suck as a psychocapitalist. I should keep all of this under my hat.

@RANTSMCPANTS I agree somewhat with you. These aren't universal, true.
I don't agree with the manipulation/resistance part. Every thing requires getting used to. Just because it's new doesn't make it unnecessary. If you're working in a big project, where you don't understand everything, is it not helpful to have a set of well defined features in the repo? Doesn't it help productivity? If you're new, probably the test part will be covered by another dev/tester, so what's the issue if you have a good setup?

@dr-ant It is persuasion at the least though. You're talking about having people that were resistant then feeling right when you tamed them into submission (which also limits people to within the bounds you've imposed which you might come to regret).

That outcome immediately validates the ego. Are you sure it did anything else? The only thing you get out of it is control or loyal minions.

That in itself can be somewhat more or less productive but if so it's probably not on account of practising BDD and there are other ways to bring people over to your side than torture.

You can put BDD on the table, but don't force feed it to people.

@RANTSMCPANTS haha I feel that's a different issue altogether.
We could argue that about everything, like you said, not just bdd.

@dr-ant It's something that people don't appreciate but the driving factors in programming are often overwhelmed with the noise of human social cognition and the darker sides of pragmatics.

@RANTSMCPANTS
"People keep making this argument it's just a matter of getting used to it, well yes if I were being tortured every day in captivity I wouldn't have much choice."

- The same thing could be said about writing code in english rather than chinese. Or writing code in Java while the new hire prefers Kotlin. Or using spaces while the rest of the project is tabs. I mean there are project rules a new hire must comply to.

"You make things ten times hard by introducing both new and unnecessary things."

- Unnecessary? Yes. But I'd argue whether having tests in the code is unnecessary.

"You can put BDD on the table, but don't force feed it to people."

- I agree with that only if it is a suggestion for the project and has not been in it all along.

It almost feels as we are somewhat miscommunicating. I am NOT saying BDD/TDD/etc should be forced on to projects. God no! It should be suggested, like you've said, tried out for some time and then decided whether to adopt it or not.

If you force something new on people then there will definitely be an immediate rejection. Putting the new thing on the table and maybe enforcing a probation period (2 sprints or so) to see how devs are coping with it and whether or not it brings value to the project -- that should work. And even if after the probation this method is ruled out, the example is already in there. It's likely that after rejection and some time for cooling off devs themselves will come back to the tech. And then, if they do, the tech could be reconsidered and probably made a part of the project.

But initially I was not talking about onboarding a new tech. English is not my native tongue, I may have expressed myself wrong. My post and comments are here to just say that these methods do add significant value as they stabilize the project and protect devs from their own mistakes. And that adopting them (correctly) is very likely to make you write much better code.

Onboarding this tech is a different topic.

@netikras The problem isn't that it's new. It's that it's a waste of time. It's new thing is an excuse at best.

If you think you can put BDD through a probation like that to "see if it's good" or "if devs like it" then it hints at not understanding BDD. It's like anti-biotics. You don't prescribe a course unless someone is truly ill. This harkens back to a time where people would take anti-biotics all the time thinking it was good to do that.

You really rarely have situations where you would want a team that does it BDD as standard.

I've seen clients seduced into splashing out for BDD and at the end of the day all they get from it is more billable hours to pay for.

Inventing a new language and then implementing an interpreter for that language is a huge overhead that is rarely needed.

BDD on the PM side, isolated to actual business logic appropriate to be specified in that way is usually less excessive than putting it devside.

@RANTSMCPANTS Interesting..

"at the end of the day all they get from it is more billable hours to pay for"

How is this measured? I mean the idea of tests is to keep the product working at all times, meaning less bugs in the future, easier (i.e. w/ less-to-none new bugs introduced) refactoring, flexible code. I do agree that initial costs are higher, but how do you measure the costs in a long run, i.e. "bugs that did not happen due to lapsuses and the client did not have to pay for fixing them"?

@netikras There's a huge difference between an idea and the reality.

There's a larger problem in general that it's very difficult to objectively measure all of these concepts such as maintainability. They really have no meaning. It's like saying fast. These human terms don't actually compute.

You don't magically get any of the promised gains by practising these things for the sake of practising them. You have to be intimately aware of how and if A leads to B leads to C.

Anything other than writing the working code is an anti-pattern first and foremost, is an added cost. When you're doing more and insisting somehow it results in doing less chances are you're getting it wrong. Even fluent programmers such as myself have some tendency to over do it and I cling tightly to minimalism.

I always try to develop for the long run and I don't need any of those. Premature optimisation? Bloating a codebase is the opposite of futureproofing.

@RANTSMCPANTS So let me see if I got your thinking right.

Code-first is the only correct way (since anything else is an antipattern). And ensuring that your code will be reusable (since you are building top-to-bottom) is more of a waste of time than the trial-and-error way, having notions of what the end result of each layer should look like (i.e. writing code and aiming for the end result rather than having the mocked end result and triaging it to the correct implementation).

Interesting.. :D Definitely not my cup of tea

@netikras Writing the code that does what you've established it needs to do or is likely enough to need to do is the minimum. That's a start point. Anything else is an upfront cost. You have to drop your guns before they do.

When I make an image I don't do yum install * but instead only the packages I need from the minimal image.

It's the same with these methodologies. You don't touch them unless it's a thing that wont jeopardise the mission or you have a problem on your plate in front of you that calls for extraordinary measures. Programming isn't that problem. [TBD]DD is not a solution to programming nor how to program, it's not a set of general solutions but specific solutions that only become relevant under certain conditions.

Reusability is not exclusive to [TBD]DD, have very little relevance. I've seen them make it worse. People keep ascribing these properties to things like readability, maintainability, reusability, etc but it's all subjective and easier said than done.

@RANTSMCPANTS I think the best we could do here is to agree to disagree. I am not trying to change your mind, I don't think you are trying to change mine's too. Personally I've made quite a number of experiments and compliance-driven development has always had significantly better results. In some cases even shorter TTM. I found it to be easier with ever changing client's desires (while the feature was WIP). And I find it very mysterious that compliance-driven dev could be a drawback in some phantom cases people keep talking about though not naming any particular ones (except for the rejection-by-team effect you've mentioned above).

If NSAIDs always relieve my headache, it would be also very difficult to believe someone saying that they don't or that there are cases where they cause it (assuming taken exactly as prescribed).

If [TBD]DD has proven to me 10 times out of 10 to be more reliable way to deliver product, I find it very difficult to believe it would have an adverse effect.

I have to admit, i didn't read all your posts, but yet wanted to add.

Just wanted to say that there really is no silver bullet and TDD is not one. If it suites yours and teams doing, by all means. But its good to remember that everything can not always be tested, it will add a lot of time to a project and its hard to sell for a customer.

In real life budgets and deadlines TDD is really hard and would require a waterfall like planning so that everything can be locked in so that you dont have to write all the layers inc. the tests again after sketching.