Setting coding priorities

Question

In the dev shops I've worked in, nobody has ever mentioned "coding priorities". I read this in a book or site somewhere, and sets the expectation of what priority should be first in the code. In places where this is not specified, what should the first priority be?

It may sound simple to say "do what the business need requires", but that could be at the expense of performance/maintainability. Many people say maintainability first, regardless, some say fulfill the need regardless.

I am a young developer, so I am probably missing the point somewhere. Of course, programming is engineering and tough because you can never have the perfect solution.

Thanks

Answer 1

I think the first question a programmer should ask is, "Do I need to write this code?" We live in a rich world of pre-existing, robust, open-sourced software. Before writing your own library or application, spend a little time looking for one that someone else has already spent months or years developing.

Answer 2

It is always a balancing act between the business requirements and maintenance of the application.

In some instances priority is out of your control. You have no choice but to adhere to business requirements, for example, legal reasons, or addressing major bugs.

In other instances there has to be a negotiation between the business requirements and long term (negative?) effects that may have on the system. Someone, a development manager for e.g., should represent the dev shop's concerns, and manage the dev work based on compromises (hopefully) in such cases.

Then there are times when priority is under your control. Then it is up to you to manage your time effectively, and deliver what you've been asked to.

So a bit of a spectrum in managing priorities. As you gain more experience, you will see how things work in different situations. In the interim, be aware, voice your concerns as necessary, and continue to do what you do best (-:

HTH and Good Luck,

KM

Answer 3

The question, as is, will be difficult to answer, because maintainability comes in many shades.

I distinguish 3 levels of maintainability:

1. readable code
2. avoiding repetition
3. architecture/refactoring

The first level is very basic, and does not cost development time. It just means that whenever you write new code (or read older code), you make it as readable as possible, perhaps adding/tuning some comments as you go.

The second level is less basic, but not too overwhelming either. It simply means that whenever you add a piece of code, you should check if there is not already something that does what you are about to do. If there is, merge the common stuff (great, you didn't have to write!). This will avoid code repetition, which means that when fixing you won't have to propagate the fix in the n'th copies.

The third level is definitely costlier. Architectural changes and refactoring on a large scale quickly eat up a few days of work.

With this list in mind, it's a bit more manageable to discuss.

• if you are in a hurry, just apply 1. and 2. and don't overconcern yourself with the architecture (unless you don't have one of course, in which case just create the simplest one that'll solve the problem)
• when you have a few spare days, or when you are not under pressure, consider refactoring if possible

In order to enable the second, I tend to maintain a TODO list of what I'd like to change but that I don't have the time to do right now. Then when I have some time on my hands, or when the opportunity arise to work on a piece of code that appear on this list and I can squeeze a few days of maintainenance, I just proceed.

Answer 4

It is always a compromise, you will have to learn to live with that. The business need is to sell stuff, either the software itself or the services it produces. Time to market can be very important for the company paying your salary. A reasonable product when it is needed is much better than a perfect product delivered too late.

If you are a junior developer you shouldn't have to figure out the right compromise, that's for the managers. You could give them some input though.

Answer 5

The main cost associated to software projects is complexity. This cost mainfests itself in the difficulty to produce software, the cost to maintain software, and the cost of failed projects amongst others.

The overriding priority of most software development teams should be to reduce complexity.

Answer 6

You're right in essentially saying that the customer is always right, however the factor that remains is the life expectancy of the product and the needs of the client.

For example- if you're working on a feature that the user needs ASAP, it's probably better to work on functionality now and fine-tune performance later. However, as time goes on, maintainability becomes important, as it's important to make sure that the feature continues to work.

(Source: I'm a young developer as well)

Answer 7

One of the biggest factors from a maintainability standpoint is: How long will this software be used? And that is often a hard question to answer, not only because software tends to outlive its original intended time-frame and usage.

Software that has a short operational life can in theory be less maintainable. - Caveats apply!

It is not uncommon for developers to get caught up in the details and miss the big picture (and yes I'm a dev and I'm guilty as charged, m'lud), or to 'go dark' and gold-plate where it's not required.

What is the major constraint on the project? Is it time, money, operational safety?