Technical Debt

April 23, 2010

Detailed Estimation Sucks

Filed under: agile techniques — jon @ 9:53 am

Pretend you have a team cranking away at a production app (likely full of technical debt). Part of the IT staff, so to speak. Management has a year’s worth of features, and of course wants to be able to plan when things will get done. This was my response to an agile coach who is working with such a team that is having trouble with their estimation accuracy.

Please have a seat. Yes, over there by the window is fine. Buckle up. You may experience some turbulence.

If you want to know “when you can get all that stuff done,” sit the team in a room, show them the list of stuff, and ask them. I’ll give you an hour. I suggest you have them use seasons from the sounds of the current mess :-)

If you really want to know within a month as to when the list of 1000 issues will be done (including the 250 that you don’t yet know about), then wait until you are about to release, and you will have a very accurate estimate.

I doubt that estimating accurately or poorly will help all that much in knowing when an entire list of stuff will be done. Especially when the list changes over time. Given that, why spend any/much energy? “Don’t polish a turd.”

Why not simply guarantee to management that the team will do their best effort. Just grab a stack of important (i.e., prioritized) stuff to do (loosely based on a logical roadmap/release plan), track the amount of things done each iteration on a chart. Skip the up-front waste of time estimating everything in detail. I mean really… just take a stab at “we can do these 20 things this iteration” and see how it goes — adjust as needed. The effort should take all of about 30 minutes each iteration depending on your tools and your team collaboration, and ability to know what those 20 things are.

Put an indication on the chart of number of total issues — but be ready to continually update this as new issues/bugs arrive (it’s lots of fun to watch the goal continually move further away). Or have the chart represent the bare minimum marketable features (bigger ticket items without the details). Now anyone can sense the rate of closure of the team towards the goal as each iteration piles on more closed issues. After two iterations, you can draw a straight line, after three, you can use fancier curve fits and show the least squares correlation coefficient <g>.

Instead of spending time estimating, spend time making the project progress “information radiator” as meaningful as possible. Believe me, developing software is merely working a to-do list. Anybody can watch a list of things getting ticked off and do a mental estimation as to rate of progress. Build a better view into what the project is actually doing and let people think about how it might look going forward — no need to debate future predictions. After all, at least your historical data is guaranteed accurate!

The only time I would estimate “more accurately” is if I have competing ideas or ways to solve a problem via wildly differing approaches. Then maybe we might want to weigh one versus the other from a business point of view because it could make a big difference in the long run.

But for an entrenched team on an entrenched product to estimate each little feature/issue/bug fix/story at the outset of each iteration? I question the value of the team’s time being spent doing that. I gave it up for Lent.

Try not doing detailed iteration estimation. It can be very liberating to just do the work as best and as fast as you can.

At some point, you and management will realize that it doesn’t matter if the team is good at estimating or not. At some point you may realize that most of the estimation process is an illusion, a grand trip into self-delusion fantasy land. The same amount of work will get done (well, more will likely get done if less time is spent estimating).

If you need to control what work gets done by when, then you prioritize mercilessly and do a good job to make development efficient (which includes smart architecture and design, among other things). If you need to speed up when the work gets done, then you need to consider resources (better or more) and/or reducing scope.

Now, if you want to spend time making the team better at estimating for their own edification (a la PSP), let them do their own estimates and track actuals and try to improve over time.

(My agile coach friend drew some aircraft analogies…) If only software were as simple as aerodynamics. I can predict quite accurately how a NACA airfoil is going to behave in 2D and 3D airflow. I have never been able to have a software team predict to that level of accuracy. Predicting software is not much different than predicting a relationship between groups of people.

Something to ponder… Why bother with estimates at all?

1. Who needs them and what are they for?
2. What happens if you are dead-on accurate?
3. What happens if you are off by 100%?
4. What if #2 == #3??
5. Are the workers going to be fired with poor estimates? Given raises with good ones?
6. How did they estimate before?
7. Is estimation the best use of their time?

We’re now ready for take-off!

February 12, 2010

Using Buzz to Take Advantage of Bureaucrats

Filed under: Philosophy — jon @ 4:47 pm

Carson Holmes made an interesting post <a href=”http://tech.groups.yahoo.com/group/agilemodeling/message/8986″ target=”_blank”>Big Consultants Use “Lean” Buzz to Take Advantage of Bureaucrats</a>

My response:

And you can bet that when Big Company and Big Consulting Inc fills out an industry survey about the success of the projects there, it will be all rosy.

Too often I have seen execs roll out large deployments of enterprise-wide systems &mdash; largely I think to get it on their resumes &mdash; with little true ability to actually measure the pre- and post-outcomes. This is just seemingly normal for large, bureaucratic organizations &mdash; even if they are ostensibly capitalist/free-market driven.

I think the problem is that very few organizations (I know of none, but there must be some) truly knows if the IT budget is delivering business value <i>as good as it could be</i> in such large organizations. For example, do you think CIOs from two companies can discuss the output of their IT staff on an absolute basis? Someone from the outside might be able to discern that one organization appears to do twice as much work as the other, with fewer people. But even that is more of a gut feel than a measurement of a consistent unit of measure.

If the output of development were easy to see and measure (e.g., painting walls or laying carpet), it would be easy to examine return on investment. Eventually, competitors that do a better job of efficiently leveraging technology for business advantage will win out in the free marketplace. But it could take years or decades to reveal bad decisions (think Y2K) — by this time the responsible individuals are long gone, or have been promoted up the chain.

(Even in the small, many times an individual developer may not be around long enough to learn the consequences of some decisions/code they made two years ago &mdash; hence not being able to learn and grow from that experience. Instead, more often than not, they see and learn from other people’s mistakes. Yet they are unable to understand the original thought processes that went into that decision, because the author is long gone.)

Until our industry is able to resolve the conundrum of how to compare expenditure versus return on IT, it will be easy for Big Consultants Inc to do Selling By Buzzword, and easy for IT execs to do Management By Magazine.

It gets worse in large bureaucracies, like the government, where there are no market forces to expunge wasteful practices.

We are indeed a nascent industry.

CMM Level 5 Beats Agile? WTH?

Filed under: Philosophy — jon @ 4:43 pm

Larry Constantine wrote a <a href=”http://tech.groups.yahoo.com/group/agile-usability/message/6751″ target=”_blank”>”Real Data” post</a> wherein he posited a question (summarizing):

<blockquote>
What would it mean to the agile community IF CMM level 5 and RUP practices actually worked significantly better than agile ones? Would that mean we should switch horses? Or would it mean we should revise agile to incorporate the best parts of other practice traditions? (And maybe shed some baggage at the same time?) Or doe the agile community have the TRUE answers, regardless of the facts?
</blockquote>
<hr>
Larry,

without reading the other 20 posts, here’s my gut reaction.

I would surmise that the success or failure of a project being attributed to the methodology is but one aspect to consider.

In a multivariate analysis of variance, just how much impact does the methodology have? Heck, we can’t hardly even say two projects are alike in too many dimensions.

In my opinion, it isn’t the process that matters nearly as much as the people. Ineptitude will never be trumped by CMM 5. Ineptitude may merely take longer to surface in a heavyweight process. Frankly, I have always felt that agile methods fare the best in the hands of really keen teams, and can fail miserably in the hands of rank amateurs who don’t “get it.” Folks that don’t “get it” are protected inside large process.

I would question the results (even without any a priori knowledge of them — since you revealed nothing in your post):

<ul>
<li> The data is anecdotal and unscientific (no double-blind studies)</li>
<li> Was the data unwittingly tainted by those who provided it?</li>
<ul>
<li> Did all the successful small agile projects pass on reporting because they don’t keep such minutia?</li>
<li> Did all firms that keep such data naturally want to look good?</li>
<li> Did all firms that spend LARGE sums of money on heavy processes sugarcoat their results so they can justify this expenditure?</li>
</ul>
<li> Just who keeps the total cost of ownership? really.</li>
<li> Who keeps the total cost of maintaining a CMM 5 level shop?</li>
<li> What about projects that failed and go under-reported — with either methodology?</li>
<li> Exactly how much data do you have on truly longitudinal studies?</li>
<ul>
<li> How many legacy systems that have been in place for 20 years were in the study?</li>
<li> How many 10 year-long agile projects have their been?</li>
</ul>
<li> Is there pressure on the data analysts to have the results appeal to the paid recipients/members?</li>
</ul>

The cynic in me also says — <b>IT DOESN’T MATTER.</b> You can’t legislate responsible behavior, and you can’t dictate a foolproof software development process.

The agile concepts are about as irrefutable as Newton’s Laws, so if you told me CMM 5 was the Holy Grail, I wouldn’t change one sentence on the agile manifesto. Agile is all about doing the best thing that works in your current situation. CMM5 certainly does not apply to 100% of the software projects… whereas the agile mindset does.

The best we can do is share experiences and loudly proclaim “<i>caveat emptor</i>” and “YMMV.”

I wonder… is it a bit like free market forces/capitalism — where you can have “sky’s the limit” wealth and abject poverty (agile); versus socialism where the range from best to worst is much narrower (heavyweight, prescriptive)?

I think we could use the <i>Super/Freakonomics</i> guys to help tease out interesting causal relationships between the findings and reality.

Testing Wordpress

Filed under: Uncategorized — jon @ 4:39 pm

Call me confused… when I “View Site” from word press, I see the original movabletype blog.

In wordpress I see blog posts from may, june, july, october, october 2009.

I also see comments from WP posts. But now I cannot see those posts at all.

In movable type I see no posts between Feb 2009 and Feb 2010.

WTH?

Something screwed up with web config on server?

October 8, 2009

Certificates Are Just That

Filed under: Philosophy — jon @ 10:14 am

Uncle Bob writes a great post tackling Scott Ambler’s poke at Scrum Certification.

While I understand the concern regarding getting a certificate for attending a two-day course. And I understand that the Scrum Alliance is now instituting an exam… I wouldn’t dream of being an outsider questioning Ken’s intentions behind the ideas. Instead, I assume he and the Scrum Alliance have nothing but the best intentions for the industry.

The world will sort this out… Welcome to free enterprise. If HR folks decide to use a piece of paper as a measure of something important to them, and it doesn’t yield the desired results, they will adapt.

If folks hire people based solely on a piece of paper, they’ll likely get inconsistent results, and be free to change their ways. Or not. If people think that doing software or managing a software project is learnable in a two-day course, they are free to act on that hypothesis. Learning is a daily privilege.

A 2-day course to get a certificate or four years at a college to get a certificate… neither truly represent the ability of an individual to perform in a certain capacity at a certain organization on a specific project.

IMHO, there isn’t much to get in a huff about… move along, nothing to see.

BTW: I am UML Certified, so hire me! (I’ll just keep it a secret that I didn’t have to take a course (just helped James Odell beta test the exam)! The certification does not test *if* you can model, but only that you know the syntax of the modeling elements. BFD.)

July 14, 2009

On Metrics

Filed under: quality — jon @ 10:14 am

I was watching Corey Haines’ video

And I had these thoughts:

A challenge that I see is not so much about gathering metrics. I have been using metrics since the days of PC-Metric and PC-Lint (IIRC). I would try to get my code and designs as good as possible, without being too crazy about it all.

Later, I added 60+ metrics and 60+ audits into Together, you could even trend your results to see progress over time with a given code base. Big whoop. I even had dreams of anonymously uploading audits & metrics to a website so people could collaborate on arriving at good, meaningful values for various metrics. (I routinely got asked “What is a good level for metric x?”)

Yea, so we all know, “You can’t improve what you don’t measure.”

But what are we trying to improve? Quality? Reliability? Agility to make changes? Profit?

Just how do we correlate a measurement to a desired outcome? Can we tie a set of metrics to their impact on the business goals for the software? Less complexity equals more profit and more (happy) customers?

Or do we stop short of that and tie metrics to achieving “quality” and presume that if we target a given application to meet the “right” amount of quality, the business value will naturally follow?

This is a difficult conundrum for our industry. But we do have to start somewhere.

In the world of engineering, there exist measurements that can be tied to desired performance and cost.

We need something similar should we want to mature beyond just seat-of-the-pants and gut-feel techniques.

I am sure some folks have it down to a science… and for them, it must be a nice competitive advantage that is probably hard to share publicly.

July 4, 2009

Independence Day, 2009. USA

Filed under: off topic — jon @ 12:19 pm

My wife, Sue, and 14 year old daughters Caroline and Heidi, their classmate Ellen, and Ellen’s mom, Estelle, embarked on an adventure on 1 July. They have crossed on foot, from France into Spain along the “French Way” route of the ancient El Camino de Santiago (Way of St. James). This was the most important pilgrimage in medieval times, and has been traveled ever since. For the girls, it will be 500 miles (800 kilometers) and more than a month. As an aside, oddly enough, in 1779, John Adams and his sons, while on a mission to get money from Paris, had to make emergency port in Finisterre (The End of the World in medieval times). They ended up following the Way of St. James in the opposite direction all the way to Paris!

In many regards, a walk on such an ancient route can give one pause to reflect. Think of all the mini-rulerships along the way and over the course of history, from small local castles, to Caesars, to local Kings, to remote Papal Kings, to dictators, to elected officials. The American experiment was such a unique opportunity to throw off the shackles of “heredity” and part ways with the past. America had no “past” to speak of. There were no generations of Kings and fiefdoms that had been fighting each other over the centuries for reasons no one could scarcely remember any longer. To learn from the past — yet forge ahead without being tethered to doing things “just because we always do them that way” — this was the opportunity facing the colonists in 1776.

For 233 years, the spirit of America continues, though for certain today, it is under assault from those elected and appointed officials who seem not to be able to think with the remotest levels of common sense or posterity. Our Founding Fathers laid their lives on the line (literally), to break away from the all-powerful dictatorship of the British Throne. They had posterity at the core of their thinking. They theorized that a government founded from the wellspring of its Creator — and not the random (at best) gene pool of Kings — to preserve the God-given freedom that *is* man’s natural course, would be the best course to set the young nation on its best path. They even knew that specific religion mattered not, but rather there was strength in having varying points of view — but certainly Godlessness was not among them. The bigger point being that human rights do not come from a King or the Government. We are naturally free, as any creature born unto this earth. We the people bestow the rights to a select few to govern. And, we the people can revoke that gift when ever we see fit. Usually on a cycle of agreed-to election times. But this is not a necessity should our elected officials go too far at destroying our way of life too quickly. After all, there is the provision for impeachment of any elected official for just such circumstances.

I urge all citizens of the world to read the Declaration of Independence. A truly amazing document that unleashed the ability of an entire nation to thrive, grow, prosper, and become the world’s protector and defender of freedom in all reaches of the globe. As if that was not enough, America became the beacon of hope that is still alive in the oppressed and less fortunate of today.

Our leaders today, our government-run educational system and universities, and our major media, are good at indoctrinating those too weak to learn for themselves, about how horrible the USA has been and continues to be. Some of our elected officials and others in power truly think the American form of government must be changed — “remaking America” — as President Obama pledged in his inaugural address. I for one, do not. The only remaking that I would like to see is a return to Common Sense, and a lessening of the stranglehold that Government is shackling us all with. I pity thou who doth not brace for 20+% inflation and truly rough times when all of the foolishness comes due in a few years.

No. We need not the remaking of America in the eyes of Progressives — that was done in the first part of the last century with fascistic groups of thugs, propaganda ministries, annexing of private land in the name of betterment for all, back-room deals that controlled the banking industry, control of what you could sell, what you could drink, and rounding up of hundreds of thousands of citizens. You say that sounds like Fascist Italy or Germany in the 20s and 30s? Brace yourself. Sit down. This was all done by administrations of Wilson, Teddy Roosevelt, and FDR. The rounding up? It was for committing a “crime” no greater than being of Japanese descent.

Think it can’t happen in America when a President and Congress are out of touch and seemingly drunk with power? Spending us into oblivion? Increasing the monetary base by 100% (3 times the record increase that occurred during WWII) and lying about the true deficit — it is closer to $100 TRILLION. Think again. It has happened.

Beware the urging of quick political action at the behest of an emergency. Thomas Paine’s words of warning in 1776 ring just as true today as ever.

Thank the educational system for ensuring folks think fascism was not practiced in America. Thank the educational system and Hollywood for equating fascism solely with evil and death camps. Thank the educational system for allowing the Communist painting of fascists as being right-wing to stick to this very day — when fascism is a plainly liberal phenomenon around full State control. Liberal Progressives (of the kind that Hillary Clinton happily proclaimed allegiance during the debates) truly believe that the State knows best. That the average citizen is not equipped to know enough to make the proper decisions about important topics.

Our leaders spout great rhetoric, but then do the opposite. Our normal checks and balances — a key part of our Founding Father’s vision — of a curious and skeptical media and free press is only alive in a few outlets. Even Pravda is jealous of the cozy relationship between mainstream media and the American administration.

So, on this 4th of July, heed not only the calls for “another burger” or “another beer”, gaze skyward not only for the display of fireworks, but give some time to pause and reflect on the true meaning of freedom. Pause to reflect on what our Founding Fathers sacrificed and the legacy they left to generations that followed. Pause to consider if our elected leaders at all levels are doing what is good for America’s future – for your children and their children… Pause to consider if there is more that you can do if the answer is “no.”

And finally, pause to give thanks to the soldiers serving today, unable to be with their loved ones and friends back home. For it has been on the backs of great men, like my father, who served selflessly to preserve our freedom and our way of life.

God bless America.

June 19, 2009

Kent Beck says “No Tests?”

Filed under: agile techniques — jon @ 10:35 am

Okay, well more like:

Kent Beck Suggests Skipping Testing for Very Short Term Projects

As discussed by Mark Levison here.

It’s like many things in software — a judgement call.

I agree wholeheartedly with Kent.

If you are in a highly exploratory phase… just trying out a few ideas to see what might work before committing to an approach, why bother with TDD?

Now, if you are lousy at design and doing exploratory work, and you prefer TDD — then use it! Use your best judgement to make that decision based on your current situation.

Caveat Emptor: I am not an expert in TDD, nor have I done it more than a handful of times.

Aside #1

I have always wondered this… as it seems to be a built-in assumption on the part of TDD advocacy. Does TDD necessarily lead to good design? Philosophically, I don’t see how it can be an immutable assertion.

Aside #2

In 2001, when we were in Snowbird for the Agile Manifesto gathering, I remember doing an example of TDD with Bob Martin. After we did a simple example in Java, I turned to another technique to “write” the tests and code. In Together, we had built a feature that allowed sequence diagrams to generate code. Writing tests as a sequence diagram was fun… create test classes, invoke application objects, create the classes for those objects, create methods, add code, execute the tests. Rinse and repeat.

Aside #3

Typically I design by starting with objects… I don’t need tests to tell me the core aspects of the system — but that is my personal choice. Features typically indicate core methods that are needed. When we need to flesh out nitty-gritty logic and what not, then I will turn to sequence diagrams — which could be done with TDD.

Aside #4

I can see where TDD would really help to benefit in ensuring folks stop coding just as soon as the test passes — assuming of course that the test is at the proper “correctness” level.

Summary

For me, I chose to be pragmatic, NOT dogmatic. I chose to use my brain to do what makes the most sense in every circumstance, not a blind allegiance to a process for process’ sake. If barging forward and doing “design and coding” works best for you and your team to flesh out ideas, go for it. Just be sure to go back in and “do the right things” once you commit to an approach that is going to stay in the code base.

June 9, 2009

Bravo Kent Beck!

Filed under: Uncategorized — jon @ 9:52 pm

In a very soul-searching way, Kent Beck reveals some frustrations here: Cracking

My response:

IMHO, you are doing the right thing, and your questioning of

May 6, 2009

Is your right-brain active?

Filed under: Philosophy — jon @ 8:29 pm

Check this out…

Right Brain Test.

Until I stepped back from work, came at it with a clear head, I could not see the image…

It is a good reminder that we in IT are often so very much focused on linear thinking, that it is hard to allow the right brain to get much air time.

Yet the right brain is where all of our creativity lies!

Older Posts »

Powered by WordPress