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.

What does a programmer need to pay attention to during the development of software? For example, some software can not be finished within the time constraints, others cannot meet the requirements of clients.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, Martijn Pieters, jwenting, Wayne M May 20 at 11:45

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
what about all of it? –  jwenting May 20 at 10:11

4 Answers 4

up vote 9 down vote accepted

You need to pay attention to all of them, but to different degrees at different times during the development process. However, you should never lose sight of any of them at all times.

It's always a balancing act between requirements, quality and time constraints and the skill lies in how you manage that balance.

At the start of the process you need to make sure you understand the requirements. From this you can work out what you can reasonably deliver in the time allowed. At this point you have to start managing the customer expectations. Don't promise that you can deliver everything, but ensure that you promise that you will deliver their core requirements.

Once you start developing you must pay equal attention to the quality and time constraints to make sure that you keep on track. However, you must not lose sight of the requirements as you could end up developing something that's not needed.

If you can manage this then you are an excellent developer.

share|improve this answer
    
Definitely. No phase can be ignored, but some of them aren't too important right now. –  user4051 Feb 21 '11 at 12:31

Requirements definition — if that's not done right, you're totally screwed no matter how great you code.

share|improve this answer
1  
+1, more if I could. If the requirements are solid the team can usually breeze through the project. We factor in a heavy buffer just to compensate for unknown/changing requirements. –  DarkStar33 Feb 21 '11 at 17:49
1  
+1 - doesn't matter if you're on track in a project if you didn't do this step, you will end up behind. –  Tyanna Feb 21 '11 at 19:43
1  
+1 Without the requirements up front it is never officially finished. –  G3D Feb 21 '11 at 22:55
    
With well defined requirements you save: 1. Frustration for the client because of getting something he didn't want. 2. Frustration for yourself because of coding something that is not useful. –  romeroqj Feb 22 '11 at 8:17

If you can't meet the requirements, you're screwed. If you can't meet the deadline, you're screwed. If you can't convince your managers that it's impossible to meet the requirements within the deadline, you're screwed (not them...). If you can convince them, you're screwed (because it'll be used to give you a poor review, you clearly lack the drive and knowledge).

Basically then, you're screwed.

About the only thing you can hope for is getting ahead of the game and start warning about bad requirements and deadlines before development even starts, and getting your concerns on paper and signed off by management higher than your project manager. That way, you have proof that you're not the one who set the overly optimistic deadline. Also, get the requirements signed off by upper management so that if they change, causing you to fail your deadline, you're once again covered.

Maybe I spent too long in organisations where there was a constant blame game going on to push blame on developers for every failure while managers and sales staff got all the praise for every success...

share|improve this answer
    
Too bad there are still lots of such organizations around :-((( Luckily, there are better ones as well, so we have more and more options. It is also important to learn to communicate well - in lots of cases the developer can also be part of the problem if (s)he says what (s)he thinks managers want to hear, rather than the harsh reality. And even reality can be expressed in many different ways, some of which are better understood by managers than others. –  Péter Török Feb 21 '11 at 13:38
    
Telling management what they want to hear only serves to put the blame on you in the end. If you raise concerns early and no one took them seriously then you should be in the clear. Email can be a shitty communication device at times, for major issues go talk to them and send a follow up email with your interpretation. –  DarkStar33 Feb 21 '11 at 17:53

The three most important phases that I feel developers need most are the ones that are always either skipped or aren't given the time they are due.

  1. Requirements gathering and definition. You need to know what you'll be coding before you can start writing or give any time estimations. You'll also be able to see if your deadline is going to be reached or if you need to renegotiate it.
  2. Design. Taking time to design what you have to code can save you hours down the line. Document the design and make sure everyone has a copy.
  3. Testing. Writing code without testing it is like racing a train. You might finish on time, but how many hours will you need to spend on fixing all the bugs?

Every single one of these will save you the time you put into them and then some.

share|improve this answer

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