Entries Tagged 'Software Development' ↓

Just got off a project where everything was specified by the customer as one liner requirements. System shall do this. System shall do that. Such old school gathering of requirements shows the lack of understanding what a customer really needs and what adds business value.

Here how software development falls apart right from the beginning. First, there is no realistic way to track metrics. Second, the business analyst have to string together what “they” think are the processes. Many requirements are likely never defined but should be or implied. No way to track that either.

Here is an example building a house to illustrate a point:

House shall have 3 bedrooms
House shall have 2 bathrooms
House shall have a kitchen
House shall have 4 electrical outlets in each room
House shall have a family room

Ok, the the analyst spends time putting together the specs and then reviews it with the customer.

Customer response:

Why am I walking through a bedroom to go from the kitchen to the family room?
Where is the shower? I said we need 2 bathrooms! (yeah but you said bathrooms, I didn’t know if you meant half-baths or full-baths)
Why are all the electrical plugs on the same wall?

This goes back and forth and then you get to the front of the house and all the subjective stuff comes into play such as what kind of door, windows, colors and it goes on and on.

So what is wrong with that? It is terribly inefficient. Once more it is a guessing game for the analysts to interpret what the customer wanted and sometimes the customer needs to be saved from themselves. Customers tend to ask for the moon when a 1 acre plot will do.

Also on the metric front, it adds no value and has no meaning. I have 200 one-liner requirements and they get broken down into 40 use cases. Some of those requirements are shared across multiple use cases. So what is the point is tracking how many requirements are complete? You could to have the PM map it all out and spend the better half of the week trying to build a burn down chart for the last week? Who cares about last week! What about this week? If I have one use case that has a single requirement that takes 30 hours to implement and another use case with 10 requirements that takes 30 hours to complete are you going to build a project plan based on the velocity of 11 requirements a week? What happens if I schedule 11 of the 1 requirement use case’s that take 30 hours to complete each? Worthless metric.

So what is the solution? Well I believe small incremental builds that continually add business value is the way to go. Agile development has been working well in that regard for years but it is not is not without issues. Stories written by product owners are either well done or not much better then the one-liner system shall requirements.

I will be discussing the requirements gathering topic in follow up articles. So what works in your shop?

Don’t you hate gathering metrics that don’t mean anything? In the 80’s it was KLOC (thousand of lines of code) in the 90’s projects got so big we had to do big bang waterfall estimates where nobody had a handle on how long it would REALLY take to complete a project. Now in the agile age we have story points but management still wants hour estimates so they can answer, “when is this done?”

All of these methods have issues with dealing with the unknown, risk, interruptions, attrition on and on and on.

I do like story point estimates. SCRUM and Paceline as well as other agile methodologies do estimate based on story pointing. A customer or product owner would describe an end user feature. The team would then apply a story point to the feature. One common method is use a fibonacci sequence of 1, 2, 3, 5, 8, 13. This was really effective and development teams would quickly have the same feel as to a story point based on amount of work, complexity and risk. Stories that were larger then 13 probably were too complex or too broad and would have to be either broken down or the product owner would rewrite the story. It is amazing how quickly the team sizes the story pretty much the same way.

Story point estimates are great because:

• They incorporate complexity and risk
• They are decided by the team
• Easy to size up an iteration once you have team velocity (number of story points complete in a cycle)

Where story points fall down:

• Management erroneously attaches hours to story points

Great article on story points vs hour estimates I recommend reading blog post from Jeff Sutherland Story Points: Why are they better then hours?

To address the deficiencies, the backlog is complete can be calculated by velocity of the team. Velocity of the team is known after several cycles have been completed. But then all the management what-if scenarios start being asked:

• What if I add this team member?
• What happens it this team member leaves or get reallocated?
• How many folks do I need if I want the backlog complete by 2nd quarter?

SCRUM tools out there do not do a good job providing this information so management and product owners can make decisions. There are other variables such as heads down time of the developers versus meetings they are attending but not coding.

Development metrics are not enough, I believe team management metrics are also in order and should be captured. Beyond story metrics, velocity should also be combined with:

Code blocks per week
Hours of coding per week
Average hours per code block

Why I think this is important is we all know interrupt driven development is unproductive. A developer working one block of 4 continuous hours will be more productive then a developer that works 4 blocks 1 hour each with meetings in between each block. Now here is a metric that management should focus on! An optimized work day for developers will have a higher velocity then an one that interrupt driven.

I would put forth that this should be measured by role: Team Lead, Developer, Test Plan Writer, Test Executor, etc.

Now if we had those metrics combined with velocity we can see how long it will take to finish this backlog of 50 stories and we now have metrics to make management decisions to try and make the team a productive as possible.

What metrics have you found to be useful?

I was having a discussion over the Friend Feed Social-Media room if people thought there were any parallels to the Dot-Com (Bomb) days with Social Web companies.   Some great points were made that there is a much larger audience now versus then and one comment that software platforms are more accommodating and the barrier to market is a lot less.   Both excellent points and the last one dovetailed into one of my other questions stuck in my head, “Why would anyone develop on the Google Application Engine knowing that they could change pricing within 90 days?”  Why?  Low cost entry and instant scalability.

Now developing on GAE does not mean success for a business.  Let us suppose the favorite application architecture discussion going these days: Twitter.   Twitter has had quite a few outages in the last month.  Clearly as a result of hockey-stick growth they are enjoying.   So the argument and test applications on GAE have been developed, why don’t they just use GAE?   Well there is one problem: Money.  Twitter is a great application with no revenue stream.   So if they developed on GAE and they hit the hockey stick, how are they going to pay for all the bandwidth, CPU and disk?   The infrastructure is no longer a fixed cost but a variable one if you want to scale that number of users.   I assume Google will place some sort of limitations on billing and application usage.   But the problem all comes down to money.   Let’s assume  Google does limit resources your application can consume.  If you app is Twitter, then do you turn off the application when those limits are reached for the month?  Surely that will not work for the business, however you can not spend more then your cash reserves allow you to spend!

Once again money becomes the single problem to crack.  More importantly, cash flow.   If the business model does not a have a revenue model built into the business plan, your dead already.   If the business model is spend money and be popular and sell, you best go play poker in Vegas.   The business has to have a revenue model that works.   If you develop on GAE, the barrier to entry is small but you have to have a scalable revenue model such that you know the cost of each user addition.   So when your business does hit the hockey curve, you can increase the resources available without worries of running out of cash.

Writing a business plan is key to the success of the business, the underlying idea for the business does not ensure success.   In that regard, there are a lot of social web companies that look very similar to the dot-com days with VC money pouring in and very little revenue coming out.  Revenue must be around the corner according to this article on Information Week

MySQL query caching is simple to implement and very beneficial to high volume websites. Query cache actually caches the query results for a given SQL query. To see if MySQL has query caching enabled issue the following command:

 mysql> show variables like 'query%';

+------------------------------+---------+

| Variable_name                | Value   |

+------------------------------+---------+

| query_alloc_block_size       | 8192    |

| query_cache_limit            | 1048576 |

| query_cache_min_res_unit     | 4096    |

| query_cache_size             | 0       |

| query_cache_type             | ON      |

| query_cache_wlock_invalidate | OFF     |

| query_prealloc_size          | 8192    |

+------------------------------+---------+

If query_cache_size is zero, then it is not being utilized. Set the cache size based on your hardware and available memory. To set the cache to 1G, issue the following command:

 mysql> set global query_cache_size=100000000;Query OK, 0 rows affected (0.00 sec)

You can check on cache query hits issuing the following commands:

MySQL query caching is simple to implement and very beneficial to high volume websites. To see if MySQL has query caching enabled issue the following command:

mysql> show variables like 'query%';

+------------------------------+---------+

| Variable_name                | Value   |

+------------------------------+---------+

| query_alloc_block_size       | 8192    |

| query_cache_limit            | 1048576 |

| query_cache_min_res_unit     | 4096    |

| query_cache_size             | 0       |

| query_cache_type             | ON      |

| query_cache_wlock_invalidate | OFF     |

| query_prealloc_size          | 8192    |

+------------------------------+---------+

If query_cache_size is zero, then it is not being utilized. Set the cache size based on your hardware and available memory. To set the cache to 1G, issue the following command:

mysql> set global query_cache_size=100000000;

Query OK, 0 rows affected (0.00 sec)

You can check on cache query hits issuing the following commands:

mysql> show status like 'qc%';

+-------------------------+----------+

| Variable_name           | Value    |

+-------------------------+----------+

| Qcache_free_blocks      | 1        |

| Qcache_free_memory      | 49988976 |

| Qcache_hits             | 1        |

| Qcache_inserts          | 1        |

| Qcache_lowmem_prunes    | 0        |

| Qcache_not_cached       | 1        |

| Qcache_queries_in_cache | 1        |

| Qcache_total_blocks     | 5        |

+-------------------------+----------+