What do you do to keep up a fast pace in a big project without throwing quality out? They say TDD increases your speed overall, according to a few case studies I found (15% longer to code, but 40% less bugs, so faster finish times overall etc)
What do you do to keep up a fast pace in a big project without throwing quality out? They say TDD increases your speed overall, according to a few case studies I found (15% longer to code, but 40% less bugs, so faster finish times overall etc)
"being productive === adding features" is a very negative way to think about development, and exactly the sort of mindset that leads to projects that grind to a halt under the weight of tech debt. Good software comes from all the parts of the process, including maintenance of the code base to reduce drag on features you'll write in the future. When you write requirements, do refactoring, test things, write documentation, etc you are being productive. Your future self will thank you for the effort you put in to the non-code work now.
The goal of software development is to deliver chargeable value to customers.
When you refactor code you do not deliver value to customers and since you have spent time and resources to do that your overall productivity from a business point of view has in fact dropped.
You do though, by reducing the future cost of delivering features. That has tremendous value. Find a company that sees good engineering as a long term investment rather than a short term way of extracting money from customers and you'll enjoy software development a lot more.
Refactoring is an internal activity. It's part of the cost of development.
Yes I will, because the cost of development will be lower. That makes my customers happy so they give me more work. I'll also have fewer defects which improves my reputation which means I can charge more.
No, your customers don't care two hoots about that.
I mostly write software for SaaS companies. Their customers (the end users of the software) don't care about it much besides seeing fewer problems and getting to use better software, but my customers (the people who own the software) really do.
Edit:
I'm not arguing that refactoring isn't necessary or important. It is. But it should be kept to a minimum because it really is a pure cost and does not deliver anything of value to end users.
Your customers are the engineering teams of software business. They sometimes need to refactor their code. But their business would prefer they didn't because that's money spent on something invisible to end users (the end customers).
Specifically in my own case, the company I work for writes software for (mostly) software product companies. When we plan what to do in a sprint 'refactoring' is part of that. We literally charge for the time we spend doing it. How long we spend refactoring is agreed by the customer's project / product manager. They understand why it's necessary and important, and they want us to do it.
reputation and trust are hard to measure, and the effect is delayed. unless you have the killer app or feature, with the internet now, word will get out. many a company has tanked their reputation.
iteration speed also makes you vulnerable to be leapfrogged. Azure vs AWS seems to me to be this. a lot of Azure stuff is great now, some of that is hindsight, but real innovation at AWS is also rare. their developer tools, aka code*, are completely underwhelming. as is cloudwatch. ec2, s3, dynamo, and general lock-in are just enough to keep a lot of people.... for now.
It absolutely is customer facing value. If shipping this feature 2 weeks later means you can ship the next 10 features in 6 months, and the alternative is shipping this feature today but with so much tech debt that you ship the next 10 features in 12 months, then that is value the customer will see.
Similarly, if your code is so shitty that you're adding bugs to the backlog faster than you're able to fix them, that's a negative for the customer. If instead you spend 2 weeks refactoring so that your bugs+ rate is lower than your bugs- rate, that's customer value right there!
I cannot understand how you don't seem to understand this basic premise of a b2c relationship. Users don't just care about the features they have today, and if your competitor gets to market slower than you but has twice the features a year or two later (due to less tech debt), you're gonna be left in the dust.
There are multiple Dilbert strips on this topic.