How software rots - Uncle Bob

#cleancode #cleanarchitecture #goodcode #unclebob #softwaredevelopement #softwaredevelopmenttips

In this video, Robert C. Martin (Uncle Bob) the author of the books Clean code and Clean Architecture speaks on how software/code degrades over time. He brings to mind the thought process that leads developers to neglect the quality of the software systems they work on and a way to both prevent and fix it. Thoughts?

[What_do_I_Think]

Most of the time it starts with bad design, bad design leads to bad code, bad code leads to difficult changes, difficult changes leads to shortcuts, shortcuts lead to even WORSE code.

All started with the managers, that did want to save time.

[cvoskuil]

You must understand feature creep fueled by incompetent management and programmers. Thirty five years in the business has given me this attitude.

[MrYerak]

Shorter answer executives, not all to blame on programers with zero deadline, becouse someone sold the customer somthing that is imposibole to provide in time

[mgbrown]

I've yet to come across a test suite I was that confident in. The number of possible states the system can have makes it near impossible for tests to catch everything.

[Codetutor-DemystifyCoding]

Because of the people in the organisation who believe that - if nine people get pregnant at same time, then baby can be delivered in one month.

[igors]

It is not the fear. It is usually some piece of software someone else created without any tests. And you have to do just a simple modification. And you don't wanna spend 10 times more time on it than you estimated.

[bterwijn]

Hey that is funny, Uncle Bob suddenly is starting to make sense. A lot of his much earlier videos were more like a weird string of consciousness, but now is successfully communicating actual useful ideas. Thanks uncle Bob.

[MagyarUS]

I always wanted to try a feature and refactor strategy where for every line of code added, and tests pass, then try and remove two lines from somewhere else so long as tests pass. At some point, this should have diminishing returns as it will be hard to find code to remove. So maybe a track the the average time in someway and once you start seeing it take way longer than average, returns have diminished.

[TokyoTransit]

nice presentation. Uncle Bob is really a good speaker!

[Maklak]

What he describes is is how code rot persists. It is created by accumulation of quick fixes over time. And programmers are not told to prettify the code, just to implement a list of fixes and features, technological debt be damned.


Uncle Bob does, however, make a pretty strong argument for having Tests.

[yash]

2:03 my latex publications are like that. they work today. i am not sure that if i touch _any_ thing in there, it will even compile or not.

[Jollyprez]

I've gotten yelled-at several times for writing tests that were too comprehensive.

[bfrank]

Fear of cleaning code is only half the problem. The other is the ridiculous churn in code from the constant addition and subtraction of features that the customer didn't ask for. To be fair though, I guess that's more of a big tech thing.

[mcsamr]

I don’t think most code culture has a proper sense of “good code”. We’ll look at code that does what it’s supposed to do, is performant, and is reasonably maintainable, but call it bad because it “looks bad”, “feels bad”, is “messy”, or isn’t “readable”, which is entirely subjective and can be addressed by good documentation and good tests. Good code is like a good knot: it should be straightforward to write, continue to work while in place, and be easy to modify/undo without breaking things.

[MMarcuzzo]

That's totally true. Refactoring is way easier with tests. Correcting stuff and detecting weird behavior as well. I've been there

[magnusmalmborn]

The tests were written by the same people who let the code get to that state... Now, do you trust them?
Ime, the best way to deal with this is to have time set aside for tinkering. You want to take a Mulligan on that thing you did that didn't turn out that great? Have at it! You want to go eye-to-eye with that Rube Goldberg-machine you discovered last sprint? Knock yourself out! Can also be used for new ideas you're not sure will pan out. After you've built a prototype you can ask for resources to do it for real. The common theme is that it should be free of expectations of immediate delivery, it should be safe time for long term activities: Explore, learn, groom the system to be in a better shape for future work.

[jacekjacenty]

Everything looks nice in theory. I nearly got fired for using tool called database cleaner to make sure tests start from predictable state. What could go wrong? Uncle Bob is naive about the legacy systems.

[yt-sh]

testing and programming
are complement to each other

[OBGynKenobi]

There's no time with 50 features on deck and less people to tackle them since the layoff.

[Slackwise]

Software rots because software people meme how proper engineers use Java, and how the correct way to architect things is a "Clean Architecture" with a bunch of rules and requirements that only introduce extra complexity until the project is a lost cause and we start a rewrite.