Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Feb 27 '11 at 12:50

This question came from our site for professional and enthusiast programmers.

3  
your first priority: accept more answers and upvote more! 638 questions asked and only 77 upvotes. That's pretty poor... –  Mitch Wheat Feb 27 '11 at 2:40
    
Good question, but does this belong on programmers? –  RQDQ Feb 27 '11 at 2:40
add comment

7 Answers

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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)

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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