Coolbits Tips

.NET and general software development tips and articles I've written.

Go Back
  • Software Development Estimating Tips

    1) Break down the tasks to no larger than a few days work, and hopefully smaller. The larger the pieces you are estimating, the more likely you are forgeting a task or step. So break it down into smaller bits.

    2) Have someone look over your estimate. Or have them put together their own estimate separately. If you both come to roughly the same numbers, you can feel more confident about your numbers.

    3) On medium-sized or larger projects, encourage customers to build in a change budget up front. Then, you've got a place to go for the funds when a change is required, and your customer contact doesn't necessarily have to get lots of approval from others.

    4) A lot of people build a "fudge factor" into their estimates. I recommend adding a buffer based on your confidence in the estimate. For example, if I'm familiar with the customer and am comfortable with how they work, my confidence is higher and my buffer might only be 5% or 10% of my total estimate. But if I'm less familiar with the customer, or the technology, or something else decreases my confidence level, I might add a buffer of 25% or more.

    5) The people who will actually write the software should create the estimates. Different developers have different skill sets and levels. What might take one developer 2 hours might take another 10.

    6) Historical information is the best predictor of the effort required to develop software. Look at past similar projects for clues on a new estimate.

    Full story

    Comments (1)

  • Superior Software Developers

    What makes someone a good software developer? Or more precisely, what qualities does a software developer exhibit that makes me interested (or even eager) to work with them again? Here are the things I am looking for in a fellow software developer:

    Asks questions appropriately. Meaning: don't ask for help on every little stupid thing, and also don't beat your head against a wall for three days before telling me - "okay, I'm stuck".

    Asks about priorities, if unsure about them.  For example, don't assume that the deadline is the most important thing, unless I've already told you that.

    Adheres to the standards on the project. I worked with a guy once who set his tab spacing to 8 characters. Can you imagine what that was like to try to read? Okay, that's a dumb example, but do it the way we have already agreed to, unless you can convince me that you have a compelling reason not to.

    Demonstrates reliability. Stop telling me you only need two more weeks, since you told me that 2 months ago, and it doesn't look like it is getting any better. Give me a real number, or don't bother making one up.

    Admits it when he/she is wrong. No one is perfect, myself included. But I can't take you seriously if you won't admit your mistakes.

    Doesn't constantly reinvent the wheel. If there is code already out there that will do what we need, why are you wasting 2 days on writing something you like better? Just use what already works and MOVE ON! (Okay, I'm guilty of this one too sometimes!)

    Takes personal responsibility for the quality of his/her code. I saw a guy once who was supposed to design and code the reports for a project. His design was useless. Everyone signed off on the design, because we were crammed for time, and well, he was writing the code anyway, so people thought he had it all in his head. Not so. The reports were slow and didn't work correctly. Another group of people came in and had to re-code the entire thing! Meanwhile, no one wanted to work with this guy, so he was put on the bench, where he started learning new technology - in other words: playing! Every day, people came in and re-wrote his crappy code, and he was goofing off. If it would have been me, I would have come in every day and offered to get those people coffee, donuts, lunch, whatever, because I would have felt guilty. If this guy felt bad - he didn't show it to the people who suffered.

    Communicates with me (and others). Tell me what is going on. Tell me if you think you'll be done early - maybe someone else needs some help. But more importantly, tell me when things are going badly. Please, I really need to know.

    Isn't selfish.  You know, other people are working on this project, too. We don't appreciate it if you take all the credit, and slap us with the blame when things go wrong. Also, don't keep all the "fun" work for yourself, and dump the crappy work on the rest of the team.

    A lot of these items may look as if they only apply to software developers who are working on team, but I think they can apply even if you are programming alone. It is still important to communicate with your manager, or your customer, or the end users. And they will quickly realize if you are selfish or unreliable.

    These are the things I look for when putting together an effective programming team.

    Full story

    Comments (5)