News for hackers. Stuff that matters.

A comment on Kent Beck: “I get paid for code that works, not for tests” (2013). Parent comment

Re:Kent Beck: “I get paid for code that works, not for tests... by marcelvaldez on Thursday December 08, 2016 @06:47PM (#13135440)
Yeah, but the problem is that managers are not engineers, they want "results" and do not have sufficient software engineering knowledge to be aware of the effects of making this type of decisions over and over again.

Eventually the software engineering department has a code base that is riddled with tech debt, to a point where changing a 3 into a 4 ACTUALLY takes 6 days.

Then management asks "WTF? What did you do? Why does it take 6 days to turn a 3 into a 4?", next comes frustration and SWEs leave the company.

I've seen this happen at 3 different companies in 3 different industries, a huge company (hundreds of devs), a medium company (50 devs), and a small company (2 devs) [1].

Every time it happened, it was because a SWE team was constantly delivering under pressure by management that disregarded the cost of writing code "that works" without ever addressing tech-debt, no matter how much the SWEs warned management.

[1] To be fair the small company only fell into that anti-pattern because neither the engineers nor the managers knew any better.

[ Parent | on HN ]
Re:Kent Beck: “I get paid for code that works, not for tests... by raldi on Thursday December 08, 2016 @07:00PM (#13135527)
Perhaps the reason you've seen this phenomenon everywhere is that the companies that don't do it tend to fail, whereas the companies that do tend to succeed and grow and hire people like you.
[ Parent | on HN ]
Re:Kent Beck: “I get paid for code that works, not for tests... by taneq on Thursday December 08, 2016 @07:23PM (#13135630)
This was one of the most important lessons I learned at my first job out of university. Beautiful, well structured, clear, simple code is nice, but the customer doesn't give a shit about it. All the customer cares about is that your product solves their problem.

By all means, if you have additional resources, invest them in refactoring and improvements and additional testing and continuous integration and all those things that make our days enjoyable and our product quality high. But your first priority has to be making sure that your product solves your customer's problem.

[ Parent | on HN ]