Tag Info

New answers tagged

0

Delivery Quality can be expressed as a function of cost and time. Future cost of software for maintenance and enhancements can only be expressed as function of current delivery quality. "Good enough is fine" --> I can live with the occasional crashes, maintenance cost, increased future feature adding cost..what I need NOW is a good enough ...


1

There are already several good answers. I would add that sometimes time to market is one of the requirements. For example, there are industries where a large fraction of sales are generated at trade shows; that means a hard deadline, and if you miss it, you've lost opportunity and probably market share. In such a case, it's typically necessary to have your ...


3

I think your reasoning is flawed because you consider "best practices" as boolean. However, it's not a question whether you apply them or not. It's "how much" you apply them. For example testing: you can do a couple of manual tests, cover the basic tests automatically, make an extensive automated suite, test also all your libraries/dependencies, ...


2

This really depends on the reaction of the customer when they get software they don't like. Very few will say, "Gee, you were right. We should have had tests." but most will feel like you should have been able to make those "simple" changes anyway. If you continue to struggle with customers, you need to stop asking them if they want you to create tests. ...


3

From what I have encountered, usually, to build what can be considered as good software, one needs to have a clear set of requirements, maybe not all of them, but at least a set of core rules which will not change. From this, you then choose your architecture, design patterns, languages and frameworks. The problem with this is that most of the times, the ...


4

I've never yet seen a customer who asked for poor-quality software. However, what they do want is the cheapest software, and they want it as soon as possible. The cheapest and quickest way to develop software is to throw something together as quickly as possible, then debug it until it does pretty much what you wanted, and doesn't crash too often. At that ...


1

Technical debt is the result of trading code quality for something else you deem more important at that moment. It can be going to market fast to get feedback. It can be shipping a vulnerability patch quickly. It can be focusing on doing one (other) thing well. Technical debt is a conscious tradeoff. It's different from making a mess.



Top 50 recent answers are included