[onion2k]

I don’t feel like I was that productive though and spent a lot of time refactoring. Eg, last 1k lines barely added any features

"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.

[mytailorisrich]

This is the engineering point of view, but in a business productivity is judged from a business point of view.

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.

[onion2k]

When you refactor code you do not deliver value to customers..

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.

[weego]

Again that isn't customer facing value. Users do not care about the costs of your business, I cannot understand how so many developers don't seem to understand the basic premise of b2c relationships. At best it's the proposition of future benefits and those benefits are all to the company not the customer.

[viklove]

> Again that isn't customer facing value.

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.

[onion2k]

I think there's a little confusion around what the 'customer' is here. You seem to believe the customer is the end user. I think of the customer as the person paying for the software. When someone buys some software they usually want it to be reasonably well written, especially if they understand the development process. If you're supplying software to a customer who understands the development process well you'll often find they're more than happy to pay for additional time to do things like refactoring, testing, documentation, etc. The really good customers insist on it and will stop buying from you if you don't include it in the cost.

[guitarbill]

if there's a feature i want as a customer, i do care if i can get that in two months vs six months vs a year. i also care that it's stable.

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.

[jariel]

If refactoring improves quality and security, that's value and 'it's a feature'. Just not a shiny one.

[mytailorisrich]

Will you be able to sell more software or increase the price of your software because you refactored some code? No, your customers don't care two hoots about that.

Refactoring is an internal activity. It's part of the cost of development.

[onion2k]

Will you be able to sell more software or increase the price of your software because you refactored some code?

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.

[mytailorisrich]

If you're arguing that you might get paid as a contractor to refactor some code therefore refactoring is a productive activity for a business point of view then you have completely missed the point.

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).

[onion2k]

I'm not arguing that at all. I'm saying that all parts of the development process are important and each part adds to what you can charge for and how much you can charge. If you're good at writing software and understand how to create a maintainable, robust, well tested code base then you can get paid for things like refactoring, documentation, testing, etc. Clients understand that writing software is more than just delivering features.

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.

[jammygit]

My hope is that the refactoring today will pay me back over the next 6 months in saved time / stability