Archive for June, 2008


1. Don’t write deeply nested code
It is bad programming style to write deeply nested code – the code has a tendency to drift across the page to the right and soon becomes unreadable. Try to limit most of your code to a maximum of two levels of indentation. This can be achieved by dividing the code into shorter functions.

2. Don’t write very large modules
A module should not contain more than 400 lines of source code. It is better to have several small modules than one large one.

3. Don’t write very long functions
Don’t write functions with more than 15 to 20 lines of code. Split large function into several smaller ones. Don’t solve the problem by writing long lines.

4. Don’t write very long lines
Don’t write very long lines. A line should not have more than 80 characters. 
Example:
if(objHideRevealPalette.tree["paletteButton.textHideIcon"].getSelected() || objHideRevealPalette.tree["paletteButton.textRevealIcon"].getSelected())

Write above line like this:
var bHide:Boolean = objHideRevealPalette.tree["paletteButton.textHideIcon"].getSelected();
var bReveal:Boolean = objHideRevealPalette.tree["paletteButton.textRevealIcon"].getSelected();
if(bHide || bReveal)

5. Variable names
Choose meaningful variable names – this is very difficult.

6. Function names
The function name must agree exactly with what the function does. It should return the kind of arguments implied by the function name. It should not surprise the reader. Use conventional names for conventional functions

7. Format programs in a consistent manner
A consistent programming style will help you, and other people, to understand your code. Different people have different styles concerning indentation, usage of spaces etc.

For example you might like to write tuples with a single comma between the elements:
{12,23,45}

Other people might use a comma followed by a blank:
{12, 23, 45}

Once you have adopted style – stick to it.
Within a larger project, the same style should be used in all parts.


All we are a good programmer but we need to avoid thinking these points when we are writing code.

  • It compiles, so it works.
  • It works here, so it works everywhere.
  • Commenting? We don’t have time to waste!
  • UML diagrams are useless.
  • Plan code so that we can reuse it is useless: we’ll end up writing everything from scratch anyway.
  • Unit tests are a waste of time.

Thanx for reading this but now we need to rethink on our code.

    How to write good code

    Posted: June 2, 2008 in Best Practice
    Tags:

    Having been coding as a programmer, we have seen and write a lot of bad code. Code is not good just because it works. So here’s a quick list of that we would better keep in mind while coding.

    1. Don’t sacrifice code maintainability to performance, unless it’s strictly necessary.

    This happens very often. You have to consider that your code is likely to be read by many persons, and some of them will read it after you might have parted from that company. Remember that you won’t remember what your own code does after few weeks. So always try to put things in the most readable and obvious form, even if this will require writing more lines of code, or having less performing code. Of course this is not so important if performance is your number one issue. Try, for instance, to avoid use of the ?: operator everybody will understand it anyway, but a good old if statement will do it, so why not going for it?

    2. Be precise as a Swiss clock, when it comes to naming conventions.

    Nobody wants to read class names or variable names that look like gibberish. Don’t be mean on the keyboard: when we type, remember that somebody else will have to read it, so be extensive.

    1. Name our variable NumberOfItems rather than items_n. Don’t use cryptic prefixes to class name. Name our class ClientMessageOperationsBasicFunctor rather than CMOpFunctor. It’s a lot more typing for us, but a lot less hassle reading for the ones that will come after us.

    2. Don’t change your conventions. If we are calling the iterators i, don’t call any of them n, ever. You will induce confusion to your reader. It doesn’t seem as important as it actually is. If you call a class ClientMessageBlockContact, then do not have ServerMessageContactBlock. Be perfect, be precise, be obsessed.

    3. Use a good and consistent indentation style.

    Never ever have more than one blank line. Don’t have trailing spaces at the end of the lines. Don’t have blank spaces or TAB characters in blank lines. A blank line must be blank, that is.Be consistent: don’t use TABs to indent in one file, and spaces in another one. Possibly, use 8-chars wide TABs to indent. If you find yourself going beyond 80 rows too often, then that could be an indication that there might be some design flaws in your program. Tweak your editor to show you the end-of-line character and the TABs.

    4. Use TODOs and FIXMEs.

    If you know that you, or somebody else, will have to return on a certain piece of code to add or modify some functionality, please mark it with a TODO. If you know that a piece of code is buggy but you can’t fix it right now, add a FIXME marker. Later on, it will be easy to grep the source tree for TODOs and FIXMEs and analyze them, especially if they’re very well commented.

    5. Comment your own code.

    Seriously: you’re going to forget, sooner than you think. Just invest 5% of your time in writing commented code. Never assume that code is self-explanatory, just write a couple of lines for everything you do. Comments are not only meant to generate doxygen documentation. You have to assume that somebody else will read your code and need to modify/extend it.

    Refining your estimation skills

    Posted: June 1, 2008 in SDLC
    Tags:

    One of the most important traits that separates junior level developers from senior level developers is the ability to accurately estimate projects. Every junior level developer I’ve ever met thinks they know how to accurately estimate a project, but few can estimate with any real accuracy. It’s taken me three years to move from the mindset that I know exactly how long X takes to the mindset that I have no clue how long anything will take. But my accuracy has increased in leaps and bounds.

    Estimation is a tricky thing: if the answer were easy to come up with, your client/manager/co-worker probably wouldn’t be asking you. As vague as the answer can be, it’s probably the most important thing you’ll ever do in a project. It determines the budget and timeline you’ll have for the project and ultimately create a baseline for measuring success. As such, it’s vital that you exercise and refine this skill as much as possible.

    Keep track of progress

    The most fundamental step toward accurate estimations is keeping track of your progress. This is easiest in small compartmentalized activities. Next time you sit down to chop out the HTML/CSS/JS of a project’s master template, time how long it takes you to do it.

    The second step is to keep track of your co-worker’s progress. As a projects get bigger, teams get bigger, and soon your estimation skills must include estimations of other developer’s time. Keep track of their progress in multiples of your time.

    All hours are not equal

    Productivity is a tricky thing, and almost impossible to account for. As developers, we know that sometimes you seem to get dozens of hours worth of work done in a day, while others it feels like you’ve accomplished nothing. Here’s a few oddities I’ve learned:

    • The longer the project schedule is, the less productive hours become. A three day long project will be much more efficient than a three month long project.
    • If you are implementing other people’s code (third party apps, existing custom framework, etc), productivity will be hampered by at least a factor of two. Writing new, clean code is far more productive (it’s more enjoyable to fix your own mistakes than someone else’s).
    • Each junior developer you add to a project reduces the efficiency of the senior developer by at least a factor of two.
    • Angry/nasty clients will severely hamper the morale (and thus productivity) of the team. Conversely, happy, thankful clients will increase productivity. Account for the attitude of your client in estimations.

    Duration versus hours

    One of the smaller lessons I’ve learned is that sometimes the determining factor in an estimation is duration, not hours. Hours can be made up in weekends, longer days, and additional developers. However, some activities will take the same duration of time no matter how many hours your throw at it.

    A good example of this is bug fixing. Bug fixing in my experience is most usually a duration-based estimation, not an hours-based estimation. Keep in mind when I say bug fixing, I mean the portion of a project’s time for bug fixing — not necessarily fixing specific bugs (which is an hours-based estimation).

    How long will it take?

    Ultimately the final answer for your estimation will come down to two different values. Hours/cost and duration. How you communicate that value is almost as important as the estimation process itself. Claiming something will take fourteen days is dramatically different than claiming something will take two weeks. Here’s a nifty little chart stolen from The Pragmatic Programmer.

    Duration Quote estimate in
    1-15 days days
    3-8 weeks weeks
    8-30 weeks months
    30+ weeks think hard before giving an estimate

    Best case, worst case, target

    Another highly effective tool in estimation is to really develop three numbers: one for the best case scenario, one for the worst case scenario, and one with the scenario you feel is most likely to be true. This is important because throughout projects, “unknown unknowns” pop up all of the time. Maybe the file-system in your subversion server just crashed and you have no source control for a week. Maybe the client got a hold put on their budget and development needs to be a paused for a week. You just never know — and the only way to account for these is by guessing. You minimize the risk of that guess by giving different scenarios.

    Your estimation is wrong

    Alright, so you’ve figured out the baseline parameters, developed a model, and calculated an estimation. You’re just about to hit Send and fire it off to your boss — but there’s one small problem: your estimation is wrong. Always remember that you’re really just guessing. Think about how confident you are with your estimation. Would you bet your next month’s salary that you’ll come in within 20% of project costs?

    For smaller operations, this probably isn’t too risky. If you underestimate a 20 hour project by 150%, you’ve only lost a little more than a week. If you underestimate a 5,000 hour project by 150%, you may be sentencing your company to an early grave.

    The good news is the same as the bad: your estimation is wrong. Managers, project managers, account executives, and clients all know that estimations are wrong. If you find out that your estimation is way off balance, you can probably remedy it somehow. As long as you accept the fact that you’re wrong early on, finding out you’re wrong isn’t so painful later on down the road.

    By: Kyle Neath

    Effective Software Estimation

    Posted: June 1, 2008 in SDLC
    Tags: ,

    These tips are taken from Software Estimation – Demystifying the Black Art by Steve McConnell, published in the Microsoft Best Practices series.  This book has proved to be an invaluable resource and I recommend it to anyone responsible for providing software estimates, be they developer, team lead or project manager.  The tips listed are not exhaustive and should be considered in their original context.

    Critical Estimation Concepts

    • When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
    • A target is a description of a desirable business objective; a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative but do not assume that it is the same.
    • Avoid using single point estimations, use ranges. Avoid using artificially narrow ranges so that you do not misrepresent the confidence in your estimates.
    • Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for over estimation. Address concerns about over estimation through planning and control, not by bias.
    • Recognize a mismatch between a project’s business target and a project’s estimate for what it is: valuable risk information that the project might not be successful. Take corrective action as early as possible.
    • Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone. Use predefined ranges in your estimates.
    • Include all necessary software development activities in your estimates, not just coding and testing. For example:
      1. Mentoring of new team members;
      2. Deployment;
      3. Requirements Clarification;
      4. Technical Reviews;
      5. Performance Tuning;
      6. Creation of Test Data.
    • On projects that last longer than a few weeks, always include allowances for overhead activities such as vacations, sick days, training days and meetings.
    • Never give an off-the-cuff estimate. Even a 15 minute estimate will be more accurate.
    • Always document assumptions embedded in an estimate.
    • Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy. For example:
      1. “This Project will take 1 year” is not very precise but could be accurate.
      2. “This Project will require 7,214 staff hours” is very precise but not accurate to the precision stated.
    • Don’t assume that effort scales up linearly as project size does. Effort and communication paths scale up exponentially.

    Fundamental Estimation Techniques

    • Look for something you can count that is a meaningful measure of the scope of work in your environment.
    • Collect historical data that allows you to compute an estimate from a count. Our organization’s past performance is the best indicator of future performance, industry data is not reliable.
    • Collect a project’s historical data as soon as possible after the end of a project.
    • At all costs, avoid using expert judgement to tweak an estimate that has been derived through computation.
    • To create task level estimates, have the people who will actually do the work create the estimate.
    • Create both Best Case and Worst Case estimates to stimulate the thinking about the full range of possible outcomes.
    • Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.
    • Re-estimate at each milestone. Base new estimates on the project’s actual progress, not on the project’s planned progress.
    • Communicate your plan to re-estimate to project stakeholders in advance.

    Estimation Scheduling Challenges

    • Do not shorten a schedule estimate without increasing the effort estimate.
      1. Larger teams require more coordination and management overhead.
      2. Larger teams introduce more communication paths which introduce more chances to miscommunication which introduces more errors.
      3. Shorter schedules require more work to be done in parallel. The more work that overlaps, the higher than chance that one piece of work will be based on another defective piece of work increasing the need for rework.
    • Reduce costs by lengthening the schedule and conducting the project with a smaller team.
    • Consider the project’s development approach in allocating schedule to different activities.

    Estimation Safety Tips

    Posted: June 1, 2008 in SDLC
    Tags:

    Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don’t do a great job of estimation. In this column I offer several safety tips to keep in mind as you prepare estimates for your project and for your individual work.

    Estimation Safety Tip No. 1: A goal is not an estimate.

    A management- or marketing-imposed delivery date is not an estimate–it is a goal. A team of a certain size and productivity level can produce only so much high-quality functionality in a given time. Estimation tutorials typically are presented as though the body of work to be done is predefined and the purpose of estimation is to determine the corresponding effort, cost, and time needed. Sometimes, though, estimation works another way. If the product absolutely must be delivered by a particular date, then the relevant estimation parameter is to determine how much functionality of given quality will fit into that time box. Commitments should be based on plausible estimates, not just desired targets. A piece of work should not be considered overdue if there was never any likelihood of completing it by the dictated target date.

    Estimation Safety Tip No. 2: The estimate you produce should be unrelated to what you think the requester wants to hear.

    If your estimate and the requester’s expectation are too far apart, then you must negotiate to reach some agreement. But don’t change your estimate simply because someone doesn’t like it. Suppose your manager requests a time estimate for some piece of work and you reply, "Two months."
    "Two months?" exclaims your manager. "My grandmother could do that in three weeks with one hand tied behind her back!"
    So you try a different estimate: "OK, how about one month?" What changed in those few seconds? Nothing! The task didn’t shrink, and you didn’t magically become more productive. Your manager just didn’t like your first answer.
    There’s no reason to reduce a thoughtfully crafted estimate simply because someone isn’t happy with it. We don’t expect a rainy day to brighten up just because we feel like going on a picnic. Nor does it make sense to alter your own prediction of the future, barring a change in factors that affect how you think that future will turn out. 

    Estimation Safety Tip No. 3: The correct answer to any request for an estimate is "Let me get back to you on that."

    Avoid giving someone a quick estimate off the top of your head, because you haven’t thought about the problem yet. You haven’t really generated an estimate; you just pulled a guess out of thin air. Unfortunately these casual guesses often sound like commitments to your coworkers. Before you provide an estimate, think through what is being requested. Then assess how much time and effort it realistically would take to deliver on that request. 

    Estimation Safety Tip No. 4: Avoid giving single-point estimates.

    Estimates contain uncertainty; that’s why they aren’t called predictions. When you provide an estimate, also state your confidence in the estimate. Are you 10, 50, or 90 percent confident that you’ll be finished within the estimated time? Alternatively, present an estimate as a range instead of a single value. Identify the minimum possible duration (or other measurable factor) for the work, the most likely or most expected value, and the maximum expected duration barring some catastrophic event. You can calculate a single, nominal-value estimate by summing the minimum possible value, four times the most likely value, and your maximum estimate for that work, and then dividing the total by six. This results in a weighted average that reflects the estimate range.
    Unfortunately, the people to whom you present a range of estimates might select the lowest value of the range as the one they want to hear. A manager who goes with the minimum estimate has chosen to manage his project at a low confidence level, with only a small likelihood of delivering on project commitments. There’s no defense against unreasonable people who reject thoughtful estimates, but at least get into the habit of acknowledging the intrinsic uncertainty associated with all prognostications.

    Estimation Safety Tip #No. 5: Incorporate contingency buffers into estimates.

    Nothing goes exactly as planned. Therefore, build some contingency time into the estimate for each chunk of work you do. These contingencies will help you accommodate any unplanned tasks that might arise, and they’ll help compensate for estimates that turn out to be too low. Contingency buffers also help you cope with risks that materialize into problems. If you don’t leave any slack in your schedule, the first unexpected situation you encounter will demolish your plans. Work to meet the nominal estimates, but commit externally to the estimates plus the contingencies.
    A manager who discards thoughtfully planned contingency buffers is making several assumptions:

    • All estimates are perfect 
    • No risks will materialize into problems 
    • There will be no growth in the requirements 
    • Nothing unexpected will happen

    These are terrible assumptions! To help a manager avoid these assumptions, you could point out some unexpected experiences from previous projects. Ask the manager if there is any reason to believe that the new project will be different and that none of those unpleasant experiences will be repeated. If no reason can be provided, then the contingency buffers should stay.
    These safety tips might not help you generate estimates with which all project stakeholders will be thrilled, but they will help you and your team deal realistically with what the future might bring.

    By: Karl Wiegers


    Project work estimation has three components: the initial first cut, commonly known as a SWAG (scientific wild-ass guess), tracking the estimate against the actual numbers, and using the schedule to see what’s happening in your project.
    If you’ve been assigned project estimates, or if your project estimates aren’t particularly close to reality, don’t fret. Try these techniques to make and learn about your estimates.

    Part 1: Create an Initial Estimate

    If you’re a project manager, you probably try to estimate the work at the beginning of the project, even if you’re assigned a project end date. Sometimes senior managers have trouble hearing what you’ve said in your estimate. I use one of these three alternatives to creating estimates for the entire project:

    1. Provide a date range for the estimate: "We’ll be able to release between May 1 and June 15." Some senior managers can’t hear the second half of that statement; they only hear May 1. If you work for a manager like that, try either of these other two suggestions.
    2. Use the word about to describe the precision of the estimate: "Five people for about nine months or 10 people for about six months." You haven’t described an end date, but you have explained the resources you’ll require.
    3. Provide a confidence level to describe the range of dates: "I have 90% confidence in June 1, and 100% confidence in Aug. 1." In my experience, even the managers who can’t hear the "between" estimate can hear my confidence levels.

    Once you have a gross estimate at the beginning of the project, you can drill down and create estimates for each of the project components. Whether you try to create precise estimates or choose to use slack buffers to deal with incomplete estimates, you will have some project estimate total.
    The problem with estimates is that they are guesses. They’re the best guesses we can make, but they’re still guesses. As the project unfolds, you ‘ll be able to acquire feedback on how well you estimated using the second part of estimation, the EQF, or estimation quality factor.

    Part 2: Track EQF to Understand the Project Estimate

    As you continue to manage the project, track your initial completion date estimate. Each month (or in a short project, each week), take five minutes out of your project team meeting and ask, "When do you think we will finish the project?" Track that estimate on a chart set up with the release dates on the Y axis, and the date that you asked the question on the X axis.
    There are two good reasons for asking this question. First, you continue to focus your project staff on completing the project. People tend to work on what you, the project manager, focus on. Second, by asking your project staff, you can discover the various confidences they have in the release date. When you look at the EQF chart, you can see if people are concerned that the project won’t meet its release date, or if they’re feeling confident about meeting or beating the release date. Then you can deal with their concerns or your own.
    When you track EQF with your project team, you’re learning more about the project and using EQF to learn how good your initial estimate was.

    Part 3: Use EQF to Manage Project Concerns

    I use the slope of the EQF to make queries like, "Tell me what’s happened in the project to make you think we will meet/beat/miss the date." When people become more optimistic or pessimistic, I want to know why. The EQF not only gives me feedback on my initial estimate; it also gives me another technique to discuss the project state with the project team.
    And once I understand the project team’s concerns, I can deal with them or elevate those concerns to my management.
    If you’re using only one of these techniques to estimate and manage your projects, consider adding the other two. Every project worth completing has some uncertainty. EQF is a great technique for displaying project uncertainty and for understanding why the team is uncertain about the project.
    The better everyone understands the project, the better your project management will be, and the more likely you are to meet your SWAG. At least you’ll know how far off your SWAG was and why. And that knowledge can help you on your next project.


    Introduction

    Object-oriented applications frequently rely on Use Cases to describe the business processes of a software application. Since use cases consist of the strategic goals and scenarios that provide value to a business domain, they can also provide insight into an application’s complexity. Deriving a reliable estimate of the size and effort an application needs, is possible by examining the actors and scenarios of a use case. Use Case Points is a project estimation method that employs a project’s use cases to produce an accurate estimate of a project’s size and effort.

    Use Case Points

    Use case modeling is an accepted and widespread technique to capture the business processes and requirements of a software application. Since they provide the functional scope of the application, analyzing their contents provides valuable insight into the effort and size needed to design and implement the application. In general, applications with large, complicated use cases take more effort to design and implement than small applications with less complicated use cases. Moreover, the time to complete the application is affected by:

    • The number of steps to complete the use case.
    • The number and complexity of the actors.
    • The technical requirements of the use case such as concurrency, security and performance.
    • Various environmental factors such as the development teams’ experience and knowledge.

    Use Case Points (UCP) is an estimation method that provides the ability to estimate an application’s size and effort from its use cases. Based on work by Gustav Karner in 1993, UCP analyzes the use case actors, scenarios and various technical and environmental factors and abstracts them into an equation.

    The equation is composed of four variables:

    1. Technical Complexity Factor (TCF).
    2. Environment Complexity Factor (ECF).
    3. Unadjusted Use Case Points (UUCP).
    4. Productivity Factor (PF).

    Each variable is defined and computed separately, using perceived values and various constants. The complete equation is:

    UCP = TCP * ECF * UUCP * PF

    Technical Complexity Factors

    Thirteen standard technical factors exist to estimate the impact on productivity that various technical issues have on an application. Each factor is weighted according to its relative impact. A weight of 0 indicates the factor is irrelevant and the value 5 means that the factor has the most impact.

    Technical Factor Description Weight
    T1 Distributed System 2
    T2 Performance 1
    T3 End User Efficiency 1
    T4 Complex internal Processing 1
    T5 Reusability 1
    T6 Easy to use 0.5
    T7 Easy to install 0.5
    T8 Portable 2
    T9 Easy to change 1
    T10 Concurrent 1
    T11 Special Security Feature 1
    T12 Provides direct access for third parties 1
    T13 Special user training facilities are required 1

     

    TCF = 0.6 + (.01*Total Factor).

     

    Environmental Complexity Factors

    Environmental Complexity estimates the impact on productivity that various environmental factors have on an application. Each environmental factor is evaluated and weighted according to its perceived impact and assigned a value between 0 and 5. A rating of 0 means the environmental factor is irrelevant for this project; 3 is average; 5 means it has strong influence.

    Environmental Factor Description Weight
    E1 Familiarity with UML 1.5
    E2

    Application Experience

    0.5
    E3 Object Oriented Experience 1
    E4 Lead analyst capability 0.5
    E5 Motivation 1
    E6 Stable Requirements 2
    E7 Part-time workers -1
    E8 Difficult Programming language 2

     

    ECF = 1.4 + (-0.03*Total Factor).

     

    Unadjusted Use Case Points (UUCP)

    Unadjusted Use Case Points are computed based on two computations:

    1. The Unadjusted Use Case Weight (UUCW) based on the total number of activities (or steps) contained in all the use case Scenarios.
    2. The Unadjusted Actor Weight (UAW) based on the combined complexity of all the use cases Actors.

    UUCW

    Individual use cases are categorized as Simple, Average or Complex, and weighted depending on the number of steps they contain – including alternative flows.

     

    Use Case Type Description Weight
    Simple A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes. 5
    Average More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes. 10
    Complex Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes. 15

    UAW

    In a similar manner, the Actors are classified as Simple, Average or Complex based on their interactions.

    Actor Type Description Weight
    Simple

    The Actor represents another system with a defined API.

    1
    Average The Actor represents another system interacting through a protocol, like TCP/IP. 2
    Complex

    The Actor is a person interacting via an interface.

    3

    Finally, the UUCP is computed by adding the UUCW and the UAW. For the sample data used in the figures, the UUCP = UUCW + UAW.

    Productivity Factor

    The Productivity Factor (PF) is a ratio of the number of man hours per use case point based on past projects. If no historical data has been collected, a figure between 15 and 30 is suggested by industry experts. A typical value is 20.

    Final Calculation

    The Use Case Points is determined by multiplying all the variables:

    UCP = TCP * ECF * UUCP * PF

    For the sample values used in this article:

    TCP = 1.07, ECF = 0.62, UUCP = 264, PF = 20.

    UCP = 1.07 * 0.62 * 264 * 20 = 3502.752 or 3503 hours.

    Dividing the UCP by 40 hours (for one man work week) = 88 man-weeks. Therefore, for the sample values in this article, it would take one developer 88 weeks (or about 22 months) to complete the application.