How seriously do you take TDD, CI/CD, automated testing, clean commits, good architecture, Agile, low coupling/high cohesion, etc ... ?

How much time do you invest in those things if you have a deadline up ahead?

Have you seen these things being valued or disregarded at the previous companies you worked for?

.

They are valued until some bonehead sets an arbitrary release date, and then everybody forgets what is important to get a good, solid, bug free production release out the door, because they have to shorten their development and testing timelines.

📍

📌

.

📌

It's either that or a slow and bug-filled descent into chaos.

If the deadline doesn't take into account the work needed to be done then something will have to be tossed out. That thing is usually quality. Just make sure the people sighing off on that decision know the consequences and the risks involved.

Adhering to good practices and consciously striving for quality is the only thing that keeps the system from degrading into a cancerous pile of hotfixes, all-nighters, burned out devs, and bugs. Do it now or pay the price tenfold later.

It's sneaky though. Things don't turn to shit in a day. It happens one subpar commit at a time. Kind of like boiling frogs... What's even worse is that the quality of your programmers does not mean shit when you pay them to forget what they know and crank out features so that a manager can look good for an afternoon.

I've seen so much time and money wasted because of shortsightedness, it makes me mad thinking about it. Tax payer money as well, gg.

Edit: I've seen it blatantly disregarded because of lack of knowledge. If you don't understand the consequences of your actions then things will turn sour. It's a shame these concerns are so easily dismissed as technical mumbo-jumbo and eccentric/esoteric rockstar programmer bullshit.

@ihatecomputers ++ for "sighing off"
Edit: also I agree

@cannonau

I edited the shit out of my comment because of all the mistakes. Then I read yours and realized I missed that one. I'm keeping it, must be some kind of Freudian slip...

When you have experience in those things, they help you to go faster not slower.

@ihatecomputers

Couldn't agree more! Some even lack of coding standard, make it harder to read and maintain..

Deadlines are arbitrary and only serve to decrease code's quality and life expectancy.

I take it quite serious. In my opinion and as found by many researchers, continuously applying such techniques and methods will lead to higher quality code and that will lead to better maintainability. As it turns out, everything is about maintainability in the long run as software WILL change. Highly maintainable software means analyzability, changeability, testability and stability are at a decent level and as such, modifications are easy and cost effective. TDD, ci/cd etc. all help enormously in creating great software. A downside however is that for this to work a lot of requirements need to be fullfilled. In addition, the developers all need to be able to properly apply these techniques, if you have any devs in your team that don't know how this may lead to lots if rework etc.; you need someone to overlook proper application and provide the proper guidance.

I absolutely love to work on high quality code bases: clean, clear, understandable, testable code. Who doesn't love that?

That's quite the word salad. I think of all of those things as a toolbox. Ideally, I use them when appropriate. Using all or even most of them at the same time would be akin to building a plastic toy car model with a team of 1000 people using the entire line of Craftsmen tools. The results would be unsatisfactory and very expensive. Basically, that's 99 percent of all software developer these days.

@CodeMasterAlex I'm fully with you. The problem is that management often does not acknowledge it because you can't provide evidence on the long term maintenance cost reduction... but as uncle bob once said, this is the job of managers like it is the job of the devs to remind management of these factors.

MANAGEMENT DOESN’T CARE ABOUT THE QUALITY OF THE CODE.

It is your responsibility to convert requirements into a working system. And the requirements also include things like maintainability, bug frequency, performance, bus factor, security and other aspects that the management didn’t even think of. Choose your tools appropriately to your situation.
If you ship crappy code, because someone pushed you to make a deadline, you take the responsibility for it.

In my company almost all of the best developers are dedicated to architecture, subsystem design, TDD, CI and CD. We have a culture of enforcing best practices via technical solutions. When you are a beginner nothing helps more than good tooling and enforced rules. When you are advanced enough you know when and how to break/bend the rules.

Of course the downside is frontup investment and complexity that has to be approved by the higher ups.

As a Tech Lead it is my responsibility to provide proof and prediction to justify the investement and to oversee the plan that we don't take shortcuts. Justifying part is always a real PITA, but after that seeing all the best practises pay off is priceless.