Estimating with limited information

Best client ever. You have gone through all the steps on the elicitation stage. You have worked on the epics broken them down properly and now have a healthy backlog of user stories that is representative of the app you will be building and now you can work on estimates. Awesome right?

Yes that would actually be awesome except in reality it just never happens. More often than not the client will want at least a ball park figure from the initial meeting when all you have is just a story.

The ideal way would be to reject this option and insist on a proper elicitation phase. Unfortunately that may not be practical. Fortunately there is a way of still getting to an estimate albeit a rough one.

Introducing function points.

Almost all business applications can be decomposed to the following major categories.

Inputs

Includes the ways available to the user to feed data to the application. For web applications this would be forms, for mobile applications this would be dialog boxes, controls etc.

Depending on the application, exotic options maybe available such as finger tracking. They would still fall under this category

Outputs

What the system displays back to the user.

Most common options would be:

  • Tables
  • Graphs
  • Messages
  • Reports

The only requirement is that the output be targeted at a human consumer.

Inquiries

Very similar to outputs with the distinctions that inquiries return results in raw format. This can be consumed by humans or machines.

The distinction is important because you rarely have to write a lot of code to get inquiries going.

Most common examples would include:

  • Database queries
  • Simple search
  • API GET to a simple resource

Logical Computations

Would include major manipulation to the data that is to be done by the system. Unless your system is purely CRUD, you will need this layer as the value add for your application.

Most common examples would include:

  • Run payroll for all employees
  • Calculate shortest distance between two points
  • Convert file types

Integrations

In the connected world your app probably works with multiple other services to bring value to the user. You need to take this into account when doing your estimates. Examples of such would be:

  • Social login
  • Connection real time technlogies. eg Pusher, Firebase
  • Remote DBs eg Big Query
  • Remote file systems eg Dropbox, S3

Multipliers

Not all items in the categories would be equal in weight. As such you need to apply certain multipliers to the items to equalize them. Based on empirical analysis of software projects by Casper Jones in the book Applied Software Measurement: Global Analysis of Productivity and Quality. We have a reasonable basis for such weights.

Note in our nomenclature we classify Logical Internal Files as Logical Computations and Logical Interface Files as Integrations.

Example

Suppose now you have come from the client meeting and you managed to pick up they would need an authentication system with Google+ and Twitter login. How would you go about that?

Starting with the categories highlighted above as a ticker list you would come up with something like this.

Epics are the major areas you we’re able to pick out. The categories are as discussed above. The complexity is a subjective opinion of the item to be built. For example in my case I consider complexity of login form in category Inputs to be low but consider a registration page in category Inputs to be high.

From this data we can now calculate the number of points based on Casper Jones multipliers.

What do the points mean?

The points have given you a size estimate but not a effort estimate. To get a effort estimate in developer hours you need to look back at previous projects to see how points map to time taken for individual teams or developers.

Let us assume that looking at previous data you note that the relation between developer hours and points for your team looks like this

    developer hours = points * 0.5

That is it takes a developer half an hour to complete a point.

Then

    developer hours = 46 * 0.5 = 23

You can thus estimate that your developers will take 23 hours to complete the user authentication.

This estimation technique requires you to keep metrics on past projects but also enables you to very quickly compute estimates once you have a solid record of past performance.

The sheet used to do the computations can be found here. https://docs.google.com/spreadsheets/d/1QEbdeK7TJ39a1efQOEuBu1J-_nP5KMUYTlYPNe7Hf2Y/edit?usp=sharing

Have you ever used point estimation on your own projects tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Software Estimation Workshop

On April 28th from 1:30 to 3:30pm at Strathmore Business School, Moringa DevShop  will be holding a workshop on scoping and estimation.

Software estimation is one of the hardest activities you can engage in. It is not uncommon to meet clients who want exact dates for the exact time and cost it will take to build their software on the first meeting.

The difficulty in this is that neither you nor the client are actually clear on what needs to be done and thus whatever estimate you give is necessarily fuzzy.

In this workshop you will learn how to come up with realistic estimates that you and your team can commit to.

You will learn all about

Process

    • User stories
    • Size estimates
    • Story points
    • T shirt sizes
    • Fibonacci sequence
    • Targets estimates commitments
    • Velocity

Tools

    • Planning poker
    • Spreadsheet templates

Common Gotchas

    • Story points as time units
    • Poor choice of units
    • Tyranny of precision over accuracy

Register now by simply fill in your details at http://goo.gl/forms/3UVfLJQTSl

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Common barriers to information hiding

A core tenet of software engineering is information hiding. OOP rose in popularity owing to how well it was able to implement the concept.

When you have information hiding working for you, an entire class of problems simply disappear. I have previously talked about the concept of complexity in software The heart of software engineering and how to manage dependencies Isolating change in software projects. Today we will be looking at some of the barriers that you will likely face in this endeavour.

Hard code

Yes code can in fact become hard. Or more precisely rigid. This happens when you have design that necessitates multiple edits to the codebase for simple changes.

An example I like to use is the case of the tax rate. Since it’s a figure that very rarely changes you will be tempted to simply use the value throughout with statements such as:

employee_net = employee_gross - employee_gross * 0.3

That statement does not seem dangerous at all, I mean at worst you could do a quick search and replace if need be. And that maybe true but what if you had reference to another 0.3?

expected_annual_return = last_year_value * 10.3

Issues like that line the path to programmer hell.

Circular dependencies

This is a nefarious one. It’s power comes from the fact that at the surface it looks like great engineering.

Lets say you have a code such as:

<?php 

class User(){
  
  function getUserData($username){
    //fetch db data logic
  }
  function changeSubscription($username){
    $login = new Login();
    if($login->checkLoggedIn()){
      //Upgrade subscription level
    }
  }
  
}
class Login(){
  function loginUser($username,$password){
    $user = new User();
    $data = $user->getUserData($username);
    if($data['password'] == Hash::value($password)){
      //user login logic
    }
  }
  function checkLoggedIn($username){
   
    //logic to check if user is online
  }
}

Hidden in the code is a circular dependency. Now you have no way of testing the User class without having first written the Login class and vice versa.

Global data

So now you have moved your constants out and now save them as global information. But you have done more than just move the constants, you have also moved items you figure get used a lot by different classes out to the global space.

The challenge that this gives you is that you now have to consider what other methods that use the same global variable are doing to it as you are writing this method. You maybe the same developer that wrote both methods, but by forcing yourself to hold this information in your head, you have inadvertently created a fertile ground for bugs.

Instead consider making use of class level variables. While the dependency is still  there, now it is made explicit. You can see at a glance how exactly all the other routines interact with the data.

How do you hide information in your own projects? Reach out to me on twitter at @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

5 ways to keep your client in the loop

Software is expensive to develop. We all know that and are more than happy to charge our clients our true worth. For worthy clients the amount is not the issue, the project will likely net them multiples of whatever you charge.

Imagine yourself as a businessperson running your own bakery. You sell cakes to the local neighbourhood residents. You meet this awesome developer who promises you that they can boost your business by 100* if only you could enable customers to order online. This sounds like a good idea and you are all in, you invest 5 month income worth of your business to building the product.

A timeline of 8 months is agreed, contracts are signed, deposits are paid everyone is happy.

One month down the line you walk by the developers office to see the progress done so far. The developer tells you that they still are setting things up but are fully confident they will make the deadline.

3 months after commencement you once more walk to the developers office and you find that they have not started yet but claim their machines are all setup. You are told that there was sufficient slack allowed in the schedule and there is still so much more time to get work done. You are a bit apprehensive but you comfort yourself, after all this guys are professionals, surely they must be.

5 months later there is now some progress and they call you to their office. Eagerly you wait as they open up the first page of your brand new web app which looks freaking fantastic! You love the landing page, the color scheme is amazing, truly reflects the essence of your business. You try to click the link to login and are promptly stopped from doing so. As it turns out the page you are looking at is the only thing that has been developed.

Our story ends here, you see it does not matter even if the developer somehow delivers the project in the three months remaining, the project is already failure. The obvious reason is that the product will not have taken the clients feedback into consideration. Even more insidious, the developer forgot a basic tenet of software engineering.

    Perception of slow development can affect your project as much as the reality of it.

You see, it is part of the developers job to provide their client with steady signs of progress.

So how could the developer have gone about this task? That is what this entry is all about.

Standardized requirements and checkoff

In a previous entry I talked about Investing in user stories. A side benefit of using user stories is that they easily avail themselves to be broken down into developer tasks.

Developer tasks are actionable items to be carried out by developers.

By breaking down the project into such tasks. Progress can be made visible as tasks are checked of and then entire user stories are marked as done.

Status meetings

Now I hate meetings as much as the next guy. But truth is that the most effective form of communication happens face to face. This meetings don’t have to be long, they just need to be regular.

Scrum practitioners have mastered the art. Their meetings are called daily standups and last a maximum of 15 minutes. All team members answer the three questions:

  1. What did you do yesterday
  2. What will you do today
  3. Are there any blockers

Status reports

Ok maybe the idea of regular meetings is too hard to swallow, what about regular reports? The basic idea is the same as meeting but now people submit their progress via email or chat.

This can be more convenient since a record exists and the reports can be done asynchronously.

Milestone reviews

As a developer, you should only write enough code for the client to review. At project onset, you can decide this review periods and set them as milestones.

Bonus points if you can tie compensation to this events.

By having clear milestones and reviews, the client is kept in the loop and their feedback is integrated on future iterations.

Walking around

Yes I know developers are professionals and don’t need someone watching over them. But this has nothing to do with the developers. By giving the client a chance to come to your office and basically walk around seeing your scrum board, burn charts, design diagrams etc. They get pleasant warm feelings about the progress of their project.

I hope it’s clear to everyone why its important for clients to have this feeling.

How do you keep your own clients in the loop? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How NOT to debug

They say patience is a virtue, if you are a developer you need saint like patience to handle the notorious case of the bug.

Ever since Grace Hopper coined the term debugging our applications have gotten much better at creating harder bugs to debug. At this age, a moth in your machine would probably not even register as a fuss worthy bug.

While there is no “right” way of finding bugs, there certainly is a “wrong” way. Today we are going to be looking at some of the most common.

Output statements

God bless Taylor Otwell for this little tidbit

    dd($value);

The dd function dumps the variable passed on to it and then halts the script. By carefully using this function and some binary search chops, you can quickly identify problem areas in your code.

Most programming languages and frameworks provide this functionality in one form or another. Also it’s very easy to implement yourself.

Just like any other good thing, if it’s overused it becomes a problem. Just like any other good thing, its frequently overused!

It’s quite easy to tell yourself that I will put this code here to test if a bug is here and remove it later, but why test the memory gods?. Perhaps you will leave it nested in a conditional with a branch that is rarely executed. At least, rarely executed when you are testing your code. Guess when the branch will get run? Did you guess in production?

So what can you do about it?

Invest in a proper debugger. A tool like xdebug may take far longer to grok but once you master it, the rewards will be worth it.

Code like hell

This one is for all the Code Ninjas out there.

Fortunately I am not a ninja myself (See Why I am not a code Ninja). I am yet to change my sentiments on the matter.

The Code like hell style of development is where the code ninja pops up his/her favourite code editor and starts spitting out code. Damn the requirements and design.

Codebases that we’re coded in this way have a tendency to hide very hard to find bugs. The bugs are usually due to ninja level stupidity that mere mortals just can not comprehend.

If you find yourself debugging such an application, I am sorry my friend, the app is the bug.

So what can you do about it?

Follow a standard development methodology. Yes, even waterfall is better than code like hell. However if you are the unfortunate soul tasked with maintaining the application, start refactoring the code as soon as you can.

Versioning? For who? For what?

Git as defined by wikipedia.

Git is a widely used source code management system for software development. It is a distributed revision control system with an emphasis on speed,data integrity,and support for distributed, non-linear workflows.

Git as commonly used.

Git is a folder that can be pushed to a remote folder called github.

This mismatch in intend and use is characterized by thousand line codebase with one commit.

Unfortunately this scenario is all too common, even today. The effect of course is if you accidentally introduce a bug. You have no way of tracing it back to its point of origin.

So what can you do about it?

Learn to use version control properly. It really is not hard. In fact by simply using gitflow 90% of your problems would disappear into thin air.

Who cares about the need

Surprise surprise most applications we’re actually created to serve a need. Digging your grimy hands into the code’s innards without the slightest clue on why it works the way it does is simply disrespectful.

What you think is a bug just might be a feature.

    My software never has bugs. It just develops random features.

Ok that was just a joke, but seriously take the time to know the original intent.

So what can you do about it?

Take sometime to first check out the documentation and unit tests before starting the debugging. None of those exist? Refer back to the section on “Code like hell”.

Fix the symptom

With a few notable exceptions, a good number of clients just can’t explain their problem well. Instead they focus on what they can easily observe. As a developer you (hopefully) can see more. You see not just a misaligned form, but a missing tag. So what is a busy developer to do? Hard code the position and fix the immediate problem or rework the entire page to bring in all missing elements?

In the first scenario, the developer has just chased away the bug, be sure it will be coming back with its brothers, sisters and beer buddies. In the second scenario the developer solved the problem that caused the bug, not just the symptom of the bug.

If it took you more than a second to figure out the right choice you may want to check out How you pay for technical debt

So what can you do about it?

Don’t settle for the obvious, dig deeper. Try to find out what is the true cause of the issue you are now experiencing. The client will be happier and you will gain insights that will help you through your entire career in software.

How do you debug in your organization? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail