-1

This question already has an answer here:

On one hand, I have been taught by various software engineering books ([1] as example) that my job as a programmer is to make the best possible software: great design, flexibility, to be easily maintained etc.

One the other hand although I realize that I actually write software for money and not for entertainment, although is very nice to write good code and plan ahead and refactor after writing and ... I wonder if it is always best for the business (after all we should be responsible). Is the business always benefiting from a best code? Maybe I'm over-engineering something, and it's not always useful?

So how should I know when to stop in the process to achieving the best possible code? I am sure that experience is something that makes a difference here, but I believe this cannot be the only answer.

[1] Uncle Bob's in Clean Code says at page 6 about the fact that:

They [managers] may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.

marked as duplicate by Doc Brown, Jim G., user40980, user53019, gnat Oct 21 '13 at 4:25

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Ain't this question is more suitable on the Project Management forum? – Maxood Oct 20 '13 at 20:41
4

There is no line between quality and time. There's the Project Management Triangle:

Project Management Triangle

Quality is a function of those other factors - time, cost, and scope. It doesn't matter what you want the quality to be, if you're dealing with fixed-cost/fixed-scope and have a reduction in available time, then quality diminishes as a result.

Perhaps what you are talking about is the "definition of done" used by a lot of different methodologies (especially Agile ones). That is up to your business and technology team to agree on. For example, on our team it means 80% unit test coverage, 80% acceptance test feature coverage, all content approved and translated by marketing teams, and any regression bugs either fixed or downgraded by the product manager. There are a few other things but you get the idea.

There's never going to be any bar for "code quality" because it means different things to different people. Pair programming and code review are useful tools for keeping the code quality reasonably high - if other people on your team can understand and maintain it without feeling sick to their stomachs, it's probably good enough.

If you want to institute metrics like checkstyle or FXCop, dependency analysis, code coverage, CRAP, etc., that's up to you and your team, you can make it part of your definition of done if you want. Your business owners will probably want to understand the value of these various things to you, why you consider them important and why they need to be done before a feature is releasable. If you can't justify it, don't do it.

  • More correctly, if you're dealing with fixed-cost/fixed-scope and have a reduction in available time, then the probability of higher quality diminishes as a result. It is possible to produce higher quality code in less time at lower cost with larger scope, but it isn't as likely. – Ross Patterson Oct 20 '13 at 21:22
  • @RossPatterson: I think I understand what you're getting at, but... higher than what? Yes, given the same overall resources, you might see variations in quality between different teams, or different projects. But if you're just playing with the variables in one project, with the same team, then in order for it to be possible to achieve the same or higher quality with fewer resources, you'd have to assume that developers are spending significant time doing work that has zero or negative impact on quality, and that this work (and not some other work) would get cut. Highly unlikely. – Aaronaught Oct 20 '13 at 21:51
  • There's a fallacy in project management that goes something like this: quality always suffers when the variables are constrained. It's simply wrong. It is possible to produce perfect results in a constrained environment. What is correct is that it is much more difficult to produce perfect results that way than in a an unconstrained environment. Put more simply, constraints do not guarantee worse results, but they do increase their probability. But +1, because you obviously understand and can express all this. – Ross Patterson Oct 21 '13 at 1:43
2

Bob Martin is talking about the tension between parties with conflicting goals,. He is suggesting that it is your responsibility as Speaker for the Code to advocate for it and for increasing its quality. He assumes that there are others who will advocate for the business's need or desire to weight other items (e.g., deadlines) higher than you will. When the tension between the desires of all the parties are in balance, the result will be optimum for the business. When any one party's desire is too strong or too weak, the result will be sub-optimum. As programmers, we can deliver perfect code, but in doing so, we may cause our business to miss its market timing and leave everyone in the company unemployed. Managers may achieve deadlines perfectly, but in doing so, they may deny us the time and resources we need to produce code of acceptable quality, leading to the same result.

  • I do not think that code quality is (always) in conflict with business needs (like minimizing development time). When managers push for releasing poorly written software now, they are probably increasing the maintenance time needed for future releases. So, by not listening to the developers saying that they need more time to write proper code, they may be going against their own interest: they obtain a local, short-term optimum but waste a lot of time in the long term. – Giorgio Oct 21 '13 at 7:13
  • @Giorgio I agree. Unfortunately, a local short-term optimum is often necessary to provide time to achieve a long-term goal later. And of course you're right - short timelines don't require poor quality. See Aaronaught's answer about the PM triangle. – Ross Patterson Oct 21 '13 at 10:13
  • I think we agree: in each situation one must decide whether to optimize in the short term or to think more long-term. – Giorgio Oct 21 '13 at 11:20
2

So how should I know when to stop in the process to achieving the best possible code? I am sure that experience is something that makes a difference here, but I believe this cannot be the only answer.

You do not need to achieve the best possible code but to write a code that is in the process of becoming the best possible and offers the least possible resistance when you push it in this direction.

When you design your program, you can check the design's quality by considering likely scenarios for the future evolution of your program's functionality and figure out how hard or how easy these developments would be in relation with the design you made.

EDIT — (A response to @Aaronaught, which is too long for a comment.) I did not mean that considering likley scenarios are the only criterium for checking robustness of a design. Of course, use cases and requirements must be fulfilled, before checking anything else. But if you consider only them, then there is a crystal clear cut between quality and time.

The best possible program is internationalised, can recover gently from errors or provide detailed diagnostics, uses a not so old GUI toolkit (if the customer cares), has a featureful data explorer that will help to spot errors in the input and so on. But while we do not need to build everything in from the beginning, it can be useful to take provisions so that these foreseeable additions can be easily made.

  • 3
    It's generally a bad idea to design or evaluate a design based on speculation as opposed to use-cases or requirements that are actually known and planned for. I've seen far worse designs created with the aim of covering "likely scenarios" vs. designs created to solve the specific problem. Of course there are patterns and practices that should be followed (like SOLID) but I don't think that's what you're saying here. – Aaronaught Oct 20 '13 at 21:55
  • @Aaronaught Agree 100%. – Ross Patterson Oct 21 '13 at 1:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.