Here is my big thought for the day:

The correct process implicitly guides people into correct behavior. The correct architecture forces code into the correct patterns.

A few weeks ago I wrote about how Tracer Bullet Architects show true leadership by creating clear and direct paths prior to the entire team coming aboard is probably the most important activity of a successful project.

However, I would like to take this one step further and suggest that if [as a team leader] you install the most correct process people will want to participate in correct and efficient behavior.

For example, when Napster was first introduced millions of people illegally downloaded music. Why? Not because they were bad people, but because they had no other mechanism for which to purchase (and own) digital copies of their favorite songs. Apple came along with iTunes giving people the first reasonably priced and easy to purchase model which included digital ownership – and the rest is history. People want to do the right thing and will given the correct means.

Building on this concept, it is possible to create project infrastructures that force developers to adhere to good practices such as SOLID. Seriously…I have done it. Some of these architectures would range from MVC/DI/IoC/Mock goodness to Tiered/Stubs/Statics/MockingIsEvil grossness, and each was a good fit given current company. It was the architectures that enforced clean lines of responsibility, increased testability, and [as a result] increased stability.

Of course people can break processes, of course they can break code, but if the correct solution is in place – they have to try really hard to do the wrong thing. If people continually are breaking process or code, then the answer is easy – you currently have the wrong solution in place.

Creating a zero friction environment is rarely rewarded by your peers; however, it is the most rewarding personal achievement one can accomplish.

If you do something correct, it is as if you did nothing at all. -God (as seen on Futurama)

Similar Posts:

• Companies Aren’t Progressive (But People Are…)
• Metrics and Wealth – It’s All Relative
• Why New Developers Should Consider Contracting
• The Blame Game: How Necessary Is Traceability?
• Don’t Go For The Doughnut

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

As we all know, perhaps the largest communication problem between a client and the developer is the misinterpretation of requirements. Client verbalizes what he/she wants, we believe we have the same mind’s eye of the scope and implementation of those ideas, and thus go merrily on our way down the wrong path.

For example, let’s say we use the simple example of the task – “Build Me A House”. Without a shadow of a doubt, the very first question that needs to be asked is – “How many bedrooms?”.

Unfortunately, alternative (and less important) questions are prioritized ahead of the basics:

• What materials should we use?
• What is your budget?
• What is your time frame?
• What about details X,Y,Z?

Do not read me wrong, these are very important questions to ask, but they are important questions to ask after the most important question of all – assuming I don’t have all the information, roughly how big is this thing?

About now I am assuming you have 2 outstanding questions; why prioritize the rough size question above all others and what is up with this stupid bedroom analogy?

Why prioritize size and complexity before questions such as budget and time? Simple, knowing the size and complexity will trigger a defensive response when the answer to all other questions are not inline with the size. For example, assume we know the budget and time frame when presented with a size or complexity that does not match, instead of being defensive and pessimistic it is common for us to become optimistic and believe we can get it done under those constraints. This of course is a huge mistake.

As for the bedroom analogy, the underlying moral of the story is – find estimation cornerstones. In houses, you make huge assumptions on roughly how large a house is based on how many bedrooms it has. 4 bedrooms? Probably 2 bathrooms, 1400-2200 ft, and a yard….just a guess, but you see my point.

Without a doubt, you will be able to find those weird 2 bedroom mansions, 4 bedroom apartments, and standard suburbia 4 bedroom houses with swimming pools and marble kitchens; however, those are the exception and not the norm. By asking how many “bedrooms” you should be able to make a huge amount of assumptions up until you get hit with a modification that breaks the norm. These “normality breakers” however are commonly very out in the open (nobody expects a house builder to come in on time and under budget if you neglected to mention the swimming pool and sun room, therefore it gets mentioned).

There are tons of estimation cornerstones (some which I myself am experimenting with) such as:

• How many Epics / Themes can I detect early on? (for those using user stories)
• How many Roles / Persona have been mentioned?
• How many integration points are needed?

Depending on your environment, there might be a completely different set of criteria you might look at as a “bedroom”; however, I do believe that you will always be able to find at least one. The client budget and time frame is always on the forefront of the discussion; however, those are variables that [regardless of what they say] are mutable, their need for a 3 bedroom house is not.

Similar Posts:

• Refinance Your Technical Debt Just Like Your Mortgage
• Why Are You Asking Me This Question?
• The Broken Iron Triangle Is Broken
• Rearranging Furniture for an Unfocused Client
• The Dangers of Git ‘R Done

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Something was recently said to me that struck a small nerve:

You know Max, one thing you don’t get is that you have worked for a ton of progressive and agile companies. There are tons of developers stuck in crappy process and code working for companies that just will never get it…

Although it would be a company’s best interest to be involved in process improvements – is it really the responsibility of the company to invoke process improvements?

A business (in a nutshell) needs to concentrate on one thing – stability. With that realization many thing become apparent; however, for this argument hopefully it is clear that most [successful] companies will not make radical changes to the same processes and procedures that caused success in the first place.

Additionally, because most of the company employees are “so deep in the forest, they can’t see the trees” it is hard for most companies to see their inefficiencies. Even worse, some companies have identified their weaknesses and after years of inaction towards a solution have written off the inefficiencies as the cost of doing business.

With no reason backed with business value all companies will actually resist change. Therefore, it is your responsibility to start the change from within the company.

First off, you most understand the pain caused by the inefficiency, and therefore can best translate the relief of that pain with a given business value. Secondly, if not you then who? If you have enough courage to talk badly behind someones back, but can’t muster the courage to confront the problem, that makes you a coward. Nobody is going to fight your fights but you.

I have worked for some crappy companies, but I have never left a company without leaving it in a better place. The company didn’t change me, I brought the change with me.

Similar Posts:

• Your Software Process Sucks : Resistance To Change
• Refinance Your Technical Debt Just Like Your Mortgage
• The Correct Process Guides Us (Tracer Architecture Cont.)
• Your Software Process Sucks : The Prelude
• What Fraggle Rock Can Teach You About The Art Of Letting Go

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

All to often I hear this phrase during an estimation meeting:

I think it’s about 20 hours, but let’s say 24 to fudge it a little…

Estimating this way brings a false sense of security that you have allotted more time than needed. Probably more correct, that small amount of extra hours placed on the estimation only shortened the gap between an optimistic timeline and reality. So why is this a poor estimation?

Single Point Estimations Stink

I have said this many times, and I will say it again – single point estimations stink. Sure you can tell the difference between a 1 hour task and a 2 hour task, but can you really tell the difference between a 20 hour task and a 24 hour task. Probably not.

Solution: Learn to break down your estimations in smaller pieces. For larger tasks, ensure you are estimating in ranges or with a process that implicitly includes a fudge factor such as Planning Poker (Point Estimation).

Fudge Factor Is Not Based On Fact

In the example above, where did the extra 4 hours come from? The majority of the time it is a gut feeling, but why can’t it be fact?

Solution: Keep track of your estimations and actual development time – you can’t fix what you can’t measure. Next, measure and understand your estimation variances. This will give you 2 action plans:

1. You can correctly pad your estimates with actual mathematical variance to improve estimation confidence.
2. You can now understand and measure estimation improvement (for example, 20% variance improved to 17% variance).

Presents 100% Confidence

Even with all your body language, chair shifting, ummming, and pre-warnings; most managers will take exactly what you say for gospel. That is because when you estimate in this fashion, you are presenting the posture to your manager, “I’m the expert and I know it will be right around 20 hours”.

Solution: Learn how to present your non-confidence in a manner that does not put the project responsibility on your shoulders. Learn to speak in estimation confidence levels that allows you to ask your manager, “I am 90% confident I can get it done in 200 hours, but if I say 100 hours I am only 30% confident. How much risk are YOU willing to take on?”

Learning to sandbag your estimates is not about tossing a couple of extra hours on a task. It is about truly understanding the things you can know, and articulating risk and concern about the things you can’t know. This way you and your manager can pad those estimations together and on the same page.

Similar Posts:

• Never Be Responsible For Your Estimations Again
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Suck At Estimation? Use The 2 Day Crutch Method.
• Do Managers Prey on Developer Pride?
• Comfort vs. Confidence – A Thin Line Between Apathy and Assurance

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Technical debt always has the same 3 questions:

1. How much is the technical debt really costing us?
2. How much will it cost to pay down this debt?
3. How will I know it is time to pay down this debt?

If developers can not provide the evidence of business value for paying off technical debt (by answering all of these questions), the majority of the time project stakeholders will defer paying off technical debt.

So how does one answer all of these questions in a way that can be understood by a project stakeholder?

1. Keep track of time spent working around the debt

First off, is it really debt? Sure it might suck working with it…sure it might not be the new cool thing…but is it really debt? Is it really causing you slow down and pain? It is not debt if the pain is not measurable, and you can’t insinuate potential improvement if you neglected to measure it.

Measuring can be as simple as keeping a log of time spent fixing bugs in a particular area, or logging perceived extra time spent working around a crappy 3rd party library. In short, find a way to measure your pain in a quantifiable manner that can be perceived by anyone as money and time wasted.

Answers the question: “How much is the technical debt really costing us?”

2. Estimate how much it will take to pay off the debt

Estimating how much time and effort it will take to pay off the debt is perhaps the easiest of the questions to answer. Simply put together your battle plan for the refactor and estimate it out. Feathers in Working Effectively with Legacy Code might even suggest actually doing the refactor 70% through and then throw it away just to truly understand the size and steps to support the change for real.

Answers the question: “How much will it cost to pay down this debt?”

3. Determine a tipping point of when it makes sense to refinance (pay it off)

Now that we have measured both the cost of the debt (debt interest) and the cost of the refactor (debt refinance costs), we can frame in the answer to if it makes sense to eliminate the debt by using a house mortgage analogy.

When refinancing your house mortgage there is only one question, “Am I going to stay in the house long enough to see a positive return on the reduction of my interest over the cost of refinancing?”.

Simply put, if it costs $3,000 to refinance and it saves you $500 a month, will you be staying in that house for at least another 6 months in order to see a return on investment?

The exact same goes for software: if the data access layer is causing us 60 hours a month in lost time, and it will cost 300 hours to refactor, does it make sense to pay this off right now knowing we will see a return in productivity in 5 months?

Answers the question: “How will I know it is time to pay down this debt?”

To summarize, presenting the short and long term project costs of technical debt is as easy as putting it in a simple house mortgage analogy. However, remember that ultimately it is the stakeholder’s decision of how they wish to carry their technical debt. Perhaps it makes more business sense to spend more money now than save money later or they emotionally are just not ready to refinance. Make your case, show the business value, and the majority of the time you will get that signature for the refactor.

Similar Posts:

• Why Your Manager Doesn’t Like To Throw Away Work (And You Do)
• Why Are You Asking Me This Question?
• Whiteboard Wednesday: Why Team Velocity Slows Down
• How Many Bedrooms Did You Say?
• Companies Aren’t Progressive (But People Are…)

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Perhaps the biggest problem area for the software industry is the inability to accurately estimate work. However, this is only because people allow themselves to give out wild ass guesses on very coarse grained and undefined pieces of work.

For example, with fairly high confidence we can tell the difference between a 1 hour task and a 2 hour task, but it is improbable that someone can tell you the difference between a 34 hour task and a 35 hour task. Here in lies the answer, better estimation comes from estimating smaller bits of work.

Regardless if you call them features or user stories, your chunks of work need to be broken down into eatable bite-sized pieces (smaller yields more accuracy). So what is small enough? The answer is the 2 Day Crutch Method.

There is only one rule of the 2 Day Crutch Method – break down features/stories whose estimations are bigger than 2 days.

This single rule causes you to practice many good habits:

• Forces further exploration/discussion of unknown or large features
• Insists task break downs of lengthy known features
• Teaches the wisdom of knowing when something is really unknown

Now I am sure that people are asking why it is called the “crutch” method. Simply put, this practice is meant to only be a crutch to aid you in your journey to being a better estimator. Depending on your team, you may need to run this process for a year or perhaps a mere month or two. I am not going to be as dogmatic as to suggest that all features can be broken down into parts that will take less than 2 days to accomplish; however, I can say that most features do fit into the 2 day method.

Whether to get some brush up practice or to fix some real estimation problems, every team should occasionally challenge themselves with the 2 day estimation method. I promise you will see benefits in 2 days or less or your money back guaranteed!

Update: If you are doing User Stories, this method really helps for you to frame in the differences between Themes and User Stories. Most people understand Epics fairly easily, but get a little hung up on the granularity differences between Themes and Stories. In short, this method might be able to flush out those differences; fits in 2 days = Story, bigger than 2 days = Theme.

Similar Posts:

• How To INVEST In Your User Stories
• How To Correctly Sandbag Your Estimates
• The Easy Way to Writing Good User Stories
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Tool Review: SlickEdit Tools

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

While in the midst of other developers, I often find myself in funny little debates about metric analysis. Which metric values determine complexity, which determine quality, and most importantly which of these values are “correct”.

A common target of these debates is Code Coverage Percentages (case in point – Is Code Coverage Really All That Useful). Some argue that 100% code coverage must be maintained, others argue that there is low ROI in maintaining that level of testing.

However in the end, regardless of metric and regardless of it’s value – what matters most is that metrics relation to your satisfaction. In other words, a metric value is only as valuable as the relational context and environment in which it is applied.

Alright, I still feel that definition is a little to wordy, so let me explain with an analogy…

It has been scientifically proven numerous times that people are happier when they are relatively wealthier than their neighbors, rather than just being wealthy. In short, a upper middle class family surrounded by middle class families is more content with their monetary status than the poorest man living on Billionare’s Avenue. Hard to imagine I know…

Metric analysis needs to be perceived in the same way. There is no “correct” value of Code Coverage Percent (nor any other metric) because it is all relative to your team and previous metric goals. For example, a team just learning to unit test might find it a great achievement to hit 70% code coverage results, a venerated team might find shame in not achieving 100%, while another team’s goals might be transfixed on ROI and call 90% “good enough”. All of these metric goals are perfectly correct in their own ways because they are directly proportional to the teams attempting to achieve them.

Just remember the fundamental reason why you started caring about the metrics in the first place, so that you can drive yourself to become healthier, wealthier, and wiser each and every day. Focus on that and before you know it you will be the richest kid on the block.

Similar Posts:

• Squeezed Links: November 2007
• The Blame Game: How Necessary Is Traceability?
• Concentrated Codesqueeze: January 2008
• Does Your Team Have STDs?
• 3 Simple Ways To Avoid Making Code Smells

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Almost all software teams run some sort of software process whether it’s Scrum, Agile, Waterfall, or Scumerfall. Each and every one of these processes includes a window of time (for example, Scrum uses the concepts of 1 week iterations).

A recent comment made me about fall out of my chair. Paraphrasing:

One of the best reasons [from a management perspective] to adopt Scrum is the fact that iterations are “accountable commitments” to what the team could accomplish in a week…

Screeeech. No. Estimations are not meant to be used as accountability rulers. They are meant for visibility.

But don’t we need estimations so that we can make business decisions and commitments; therefor aren’t they for accountability? Although, the last sentence would suggest a maybe…still a resounding – no.

Let me make something perfectly clear to everyone reading – nobody should ever be held accountable for estimations. Estimations are naturally shitty, wrong, and optimistic, so why even continue to do them? Because we need the business visibility of how long software is going to take, and as a measurement stick if we can continue the current game plan or react to a different (less optimistic) reality.

I want to repeat that – it gives early visibility to know that our business schedules will work, or early warning they will not so we can react accordingly.

So you are a team manager a few weeks away from a deadline that appears is not going to be meet. What are you to do? Here are a few things to avoid:

• Ignore the early warning signs and pray for a miracle
• Guilt or force your team into working overtime
• Don’t start preparing upper-management that timelines may slip
• Post Deadline: Chew out your team for not making the deadline

Alright, what should you do? Here are a few ideas:

• Realign management strategy
• Bribe the team into working late with food, bonuses, or tech gizmos
• Post Deadline: Aid your team in providing better estimations

Being middle management should be one of the hardest jobs. I have equated software management to being an Army Sergeant, and how you handle the tough decisions of this scenario really draw parallel. You don’t push hard against the officers – shit rolls down hill onto your troops. You don’t rally the troops to accomplish the mission – the overall strategy goes to hell. Either way, you are not a popular person but that is because you make all the hard decisions that everyone else skirts around.

Similar Posts:

• Quit Sweeping Known Uncertainity Under The Rug
• The Officers vs. Sergeants Syndrome
• The Blame Game: How Necessary Is Traceability?
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Never Be Responsible For Your Estimations Again

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

A timeless process anti-pattern is when customers create a feature request and completely neglect to frame it in the phrase of a problem, rather they fill in what they perceive to be the solution. I simply call these – solution requests.

So what does the anatomy of a solution request really look like? Let’s first look what a good user story might look like:

As a paid customer, I can export my daily budget numbers to a spreadsheet.

Simple and small little user story. It doesn’t exactly explain why the problem exists, but some user stories are only meant to facilitate communication so the developer can understand the problem better.

Now here is a “solution” request:

As a paid customer, I can export my daily budget numbers to a spreadsheet. This will be accomplished by putting a button on the accounts page. This spreadsheet will be in CSV format with column A being the Total number, and D32 being the sum of all numbers.

This user story sucks, and rightfully so for a number of reasons:

Implementation Expectations

Who is it that makes feature requests? CEOs, paying customers, managers…in short, people from the top.

Solution requests are a Usability Engineers nightmare. Expectations to accomplish the feature (with the proposed solution) leaves very little maneuvering room if you are not willing to fight for it. Who knows usability habits better – a designer or the secretary?

Lack of Problem Understanding

Most user stories and feature requests are purposefully left vague as to engage the developer in conversation about the problem domain and possible solutions. When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for.

It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.

Solution, Party of 1

Assuming you have ignored my last two bullet points and have implemented the solution request. Probability is you have a solution that only solves one persons needs.

Without understanding the true problem, nor giving thought to how other people might benefit from the feature, you have created a feature that will probably be consumed by only one person (if that).

Allowing your clients and customers to create solution requests is just another weak link in the process chain that will allow for them to overrun and manipulate your design, process, and sometimes success of a project. Nip this anti-pattern in the butt by almost sounding Alex Trebek-ish,

Can you please phrase that in a problem?

Similar Posts:

• How To INVEST In Your User Stories
• The Dangers of Git ‘R Done
• When Quality Service Affects Quality Software
• The Easy Way to Writing Good User Stories
• 2 Pennies and a Tootsie Roll

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Recently, I read an interesting thought about how the future of all software is bloatware. While I do agree with this, I feel the extreme holds true as well that in the future (or even now) we will be saturated with smaller niche products otherwise known as – Product Splintering.

Product Splintering is a marketing term to describe when a company purposefully splits or “splinters” a product into multiple products. You need not look any farther than your toothpaste isle to see an example of this in action. A Mega-Does-Everything Toothpaste does not exist; instead we have whiteners, fresheners, kid friendly, and clean mint. They have essentially made one core product and spun 10-20 unique niche products from it.

Why would a company do this instead of creating one really great product? There are a number of reasons…

Niche “Me” Fullfillment

First and foremost with product splintering is the marketers ability to prey on the consumers want to feel “special”. This is exactly why modern coffee shops tolerate people ordering triple-shot-grande-non-fat-dry-cappuccino (yep, that’s my order).

When you go niche, people feel they are getting a specialized just-for-them product. The connection between the consumers current problem and a prominent solution increases the ability for a sale.

For example, although Toothpaste X may whiten teeth better than Super Whitening Toothpaste Y, Toothpaste Y has the higher ability to sell to consumers looking for that specific attribute. The consumer will implicitly connect more with the product willing to solve their current problem (i.e. yellow teeth). Rinse and repeat with numerous dental problems, and you have an army of products willing to solve any specific problem.

Software in the future may also become smaller and more specialized solving only the one or two biggest problems.

Market Saturation

Is it better to have one product on the shelf or ten? You guessed it, having more products on the shelf all branded in the same fashion takes up more physical real estate on the shelf. In turn, it takes up more of your attention and raises the probability for you to buy their product.

This actually happens on the internet all the time. Think about it – is it better to own one video game store or twenty video game stores? Bigger footprint in the search engines, bigger footprint in PPC, and a higher probability for resales even if the consumer changes stores.

The New Factor

People love “new” stuff, and this is why small business will always have a chance. Is toothpaste new? Nope. Cars, nope. Underwear, nope. Yet there are plenty of “new” products coming out in those niches, some of which on nothing more than rebranded original products.

When we splinter products and apply different names to them, it gives us a better opportunity to remarket the old as “new”

So where does all this hip, new marketing information take us? Well, it does point exactly to the model that some Micro ISV’s are taking to publish their software solutions. 37 Signals probably being at the forefront of this niche, single solution products – but there are many many others. How about all those XHTML splicing services such as PSD Gator? One problem, one service option.

Is bloatware still a problem in future software? Of course, without question. Is product splintering an equal player in this ever growing web world. Yes…yep…you know it…you betcha…it’s a go…you get the point…. ;)

Similar Posts:

• Customer Polarizing – Why Microsoft Will Always Be A Mediocre Giant
• If You Aren’t The Caretaker, Why Are You The Product Owner?
• What Your Dog Can Teach You About Building Teams
• Sell Yourself With Business Benefits (And Not Geek Speak)
• Extra Squeezed Links: July 2007

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.