Tell me more ×
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.
up vote 1 down vote favorite

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
8  
the phase where I get paid ;) – Pemdas Feb 21 '11 at 14:54
ha. You probably writing code for your boss, not for yourself...... – Jervis Feb 22 '11 at 9:12

4 Answers

up vote 8 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. – Graham Lee Feb 21 '11 at 12:31
Yes. I agree with you. – Jervis Feb 22 '11 at 9:35
up vote 28 down vote

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

share|improve this answer
1  
+1 - this is the number one failing of many projects. – Ozz Feb 21 '11 at 13:49
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. – horhay.romero Feb 22 '11 at 8:17
up vote 1 down vote

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
up vote 1 down vote

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

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.