The logical conclusions

Monday, 12 March 2012 15:22 Written by AdventureTech 0 Comments

Feeling a bit inspired by the recent DirectTV commericals I figured it's about time to apply the same rational thought patterns to the waterfall methodology.

When have a deadline approaching, you work all night.
When you work all night, you don't get enough sleep.
When you don't get enough sleep, you turn into a zombie.
When you turn into a zombie, you start eating your co-workers.
Don't eat your co-workers, get rid of waterfall.

When you try to generate an accurate project timeline you start guessing.
When you start guessing, you start grasping at straws.
When run out of straws to grasp at, you look for more.
When you look for more straws, you go looking through trash.
When you go looking through trash, you find yourself in a dumpster.
Don't go dumpster diving, get rid of waterfall.

When you plan too much, you can't make decisions later.
When you can't make decisions later, things will need to change.
When things need to change, you need to change directions.
When you can't switch directions, you drive off an oncoming cliff.
Don't drive off a cliff, get rid of waterfall.

When you estimate a feature wrong, your boss wants you to improve.
When your boss wants you to improve, you practice estimating.
When you practice estimating, you estimate how many tacos you can eat.
When you practice eating tacos all day, you spend all night in the bathroom.
Don't spend all night in a bathroom, get rid of waterfall.

When requirements can't change, the customer wants to change them.
When the customer can't change them, the customer gets mad.
When the customer gets mad at you, you get mad.
When you get mad, you go home mad.
When you go home mad, your mother in-law stops by.
When your mother in-law stops by, she tells you everything you are doing wrong.
When she tells you everything you are doing wrong, you punch her in the face.
Don't punch your mother in-law in the face, get rid of waterfall.

Did you like this? Share it:

Technical Debt: When Deadlines Are Met, Bad Decisions Are Forgotten (But Bad Code Lives On)

Wednesday, 28 September 2011 11:26 Written by AdventureTech 2 Comments

All of us are familiar with debt and the challenges that come with it, but it may surprise you to learn that many Chief Information Officers are not familiar with a very real and growing problem and the serious consequences it poses to their companies:

Technical Debt.

It can cause project failure, resignations, firings, employee disengagement and potential business failure. The culprits are not always who you think, but it is undeniably a leadership responsibility.

So how do you know if your company has Technical Debt? Here are a few symptoms:

“What do you mean it’s going to take 2 months to make that change?… It seems like such a simple thing!…”

“My IT department is always putting out fires. No new development seems to happen…”

“We have so many systems and none of them seem to talk to each other…”

“We can’t seem to keep good developers here very long…”

ACCRUING TECHNICAL DEBT

1) Deadlines and Other Original Sins
When developers are forced to meet impulse deadlines that don’t reconcile to good metrics, quality suffers. The familiar pattern is to ram code in and fix it later. The trouble is that this type of code is rarely fixed because the software is now working, the deadline has been met and the ramming forgotten during a project completion round of drinks.

The impetus to “fix it later” disappears rapidly. New projects start queuing up and spending time replacing the "coat-hangers and chewing gum code" seems like an unjustifiable waste of time to management. When deadlines are met – bad decisions are forgotten. Let’s just live with it now that it’s in production. Just deal with it…

Developers who warn that this choice leads to less maintainable code in the long run are often given blank stares or labeled complainers by decision makers. This is not a message leadership wants to hear since the option to do it correctly the first time has now passed.

2) The Golf Course and Lobbyists
Software decisions made for relationship-sake, or those pushed down from a CEO to pacify the Sales staff, create ugly integration compromises. These expedient decisions become a permanent legacy for conducting business even when the protagonists are long departed.

While IT was never consulted, they are forced to assume this technical debt and act as historian, librarian and janitor to recount those decisions to future CEOs and other new staff.

3) Compounding Interest
Badly written software that has become part of everyday company life must now be handled with kid gloves. Soon, much of your future software must now comply with that original sin just to maintain operations and that building upon shaky foundations becomes permanently institutionalized in your IT culture.

There is pain involved to developers, users and the company in changing bad code. The pain of writing on top of bad code is often less than reversing that bad decision. As a result, bad code spreads by dependency and your inability to maintain good code hygiene creates generation after generation after generation of pain.

4) Invisibility Cloaks and IT Magic
The biggest cause of lowered developer productivity is Technical Debt.

Technical Debt exists in every line of code and every application. Because it’s in the code, it’s simply not visible to leadership. Developers mostly do a terrible job of explaining this concept because it sounds like whining techno-babble.

Leadership experiences the phenomenon but never directly like a developer or an end-user – they experience it as company inertia. By the time it reaches leadership, most of the harm has already been done.

Technical Debt factors solidly into a negative perception of IT and actively helps to erode client confidence.

5) Keepers of the Code
The world used to be a much simpler place for developers 20+ years ago. Imagine learning history 300+ years ago… not as much to know – text books would have been thinner. Things moved at a slower rate but in 2011 technology moves so quickly it’s the equivalent to jumping aboard a moving train.

As languages evolve, older code becomes increasingly difficult to maintain. Conflicts also arise when companies want to keep the investment in their original applications while developers want to remain current with their skills. Companies who don’t modernize their code base lose good developers, keep bad ones, and continue to increase their technical debt.

Are there bad developers? Sure – just as there are bad recruiters and sales people. The analogies and repercussions are somewhat similar, with one important difference:

Code outlives individuals. You can’t fire code; it is kept by companies and inherited by successive developers.

When developers get aboard the "quick-over-correct" train, Technical Debt is accumulated. This debt is invisible to leadership while that individual remains as an employee and is often only ever exposed once that employee leaves. Much of this is a factor of how they haven't been trained.

While technologies and languages change, there are principles to development – to making code clean and maintainable – that don’t change that much. This is where IT leadership has an increasingly important role and why your ultimate decision on who to work with, and understanding how they work, is critical to the short-and-long-term health of your company's IT infrastructure.

Did you like this? Share it:

Lean & Agile : A Panel Discussion

Thursday, 25 August 2011 13:02 Written by AdventureTech 2 Comments

Today we have short Q&A about agile practices with out esteemed guests Winston Churchill, Albert Einstein, Mark Twain, Martin Luther King, Jr, Gandhi, Bruce Lee, & Franklin D. Roosevelt.

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Churchill: The farther backward you can look, the farther forward you are likely to see.

Albert Einstein: A man should look for what is, and not for what he thinks should be.

Question: Is this because full discovery early on is hard to achieve?

Martin Luther King, Jr.: Everything that we see is a shadow cast by that which we do not see.

Albert Einstein: Occurrences in this domain are beyond the reach of exact prediction because of the variety of factors in operation, not because of any lack of order in nature.

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Gandhi: I do not want to foresee the future. I am concerned with taking care of the present. God has given me no control over the moment following.

Mark Twain: I was gratified to be able to answer promptly, and I did. I said I didn't know.

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Albert Einstein: No problem can be solved from the same level of consciousness that created it.

Mark Twain: Get your facts first, then you can distort them as you please.

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Bruce Lee: Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Albert Einstein: Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Bruce Lee: Learn the principle, abide by the principle, and dissolve the principle. In short, enter a mold without being caged in it. Obey the principle without being bound by it.

Franklin D. Roosevelt: One thing is sure. We have to do something. We have to do the best we know how at the moment… If it doesn't turn out right, we can modify it as we go along.

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Churchill: To improve is to change; to be perfect is to change often.

Bruce Lee: All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns.

Gandhi: Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position.

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Churchill: The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end; there it is.

Mark Twain: Let us make a special effort to stop communicating with each other, so we can have some conversation.

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Churchill: A lie gets halfway around the world before the truth has a chance to get its pants on.

Gandhi: An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it.

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Franklin D. Roosevelt: Are you laboring under the impression that I read these memoranda of yours? I can't even lift them.

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Martin Luther King, Jr.: You don't have to see the whole staircase, just take the first step.

Franklin D. Roosevelt: There are many ways of going forward, but only one way of standing still.

Bruce Lee: Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Franklin D. Roosevelt: The only thing we have to fear is fear itself.

Did you like this? Share it:

Open Mouth, Insert Software Toolbox

Monday, 25 April 2011 11:42 Written by Troy Tuttle 0 Comments

Image via Wikipedia

So often we hear the phrase, “I have many tools in my software development toolbox, and I like to use the correct tool for the job.” It sounds good. It appears to be a responsible approach. After all, why wouldn’t we want someone to have multiple tools at their disposal?

The whole toolbox metaphor is fine on the surface. My problem with it stems from the incidentals in the discussion. In my experience, most people who reference having a “software toolbox” are really hiding from a more direct questioning or discussion of specific practices or methods. Instead of advocating for those methods they believe work, or more importantly, listening to others advocate for their methods, many in our field throw up the “toolbox” as a defense mechanism. It makes for a clean exit too. The problem is this mechanism limits learning for everyone involved. The “software toolbox” is a conversation ender, not a conversation starter.

With that said, I am going to put my toolbox where my mouth is.

First, my obligatory disclaimer: Individual results will likely vary. Past performance does not guarantee future success. Your specific context and corporate culture are critical factors when deciding which tools are best for you. This is not intended as a comprehensive list.

Troy’s State-of-the-Art Software Toolbox:

Small Iterative Development Cycles: Software work is knowledge based. Knowledge in software is best improved by frequent feedback cycles. Early information feedback allows the team and customer to learn and improve at a much faster rate than when iterative approaches are not used.
Source: Extreme Programming, Scrum
Explicit Work-In-Progress Limits: Even when working iteratively, teams will often have too much WIP. Ever observe a Scrum team start every single user story by the first day? I have, and without an explicit policy limiting work-in-progress, teams and managers will try to push too much work into the system. WIP limits allow a team to begin finishing work instead of starting more work. Team context switching is minimized, giving the team the opportunity to improve quality.
Source: Kanban for software
Just-In-Time Planning: Plan just for what you can do, and nothing more. There is no waterfall-style comprehensive requirements document with this approach. Nor is it the heavy backlog grooming practices frequently seen in some Agile teams where user stories are analyzed and specified in detail months before they are implemented. Just-in-time planning also means no commitment-based time-boxed iterations. Optimal planning occurs when the the team is provided with the best thing to work on next, no more and no less.
Source: Kanban for software
High Discipline, Low Ceremony Engineering Practices: Emphasize practices that encourage collaboration and short feedback cycles. TDD/BDD and a continuous integration server are a great start. After-the-fact, formal code reviews are typically too late to add anything other than rework. Code metrics are fine, but be careful what you measure. Are your code metrics making the code easier to understand and change, or are you happy just to apply “standards” to your code? Covering code with tests is a good thing. But higher code coverage doesn’t automatically mean your code base is functioning the way your customer wants.
Source: Extreme Programming
Kaizen: Continuous improvement may come from inspect and adapt, PDCA, or other methods. It doesn’t matter if you prefer one over the other as long as you build an information feedback loop into your process. At the basic level, provide enough oxygen to the team to reflect, share ideas, and improve. Some teams may require regularly scheduled retrospectives, others may perform mini retrospectives or spontaneous Kaizen events during the project.
Source: Extreme Programming, Scrum, Kanban for software

I’m hoping this is valuable information for you. This is my toolbox, and these are some of the more valuable tools to me. If I show you mine, will you show me yours?

Will these work for you? I don’t know, that’s for you to decide. I just know that they work for me today. If I were a part of a brand new software team tomorrow, this is where I would start our discussion. And hopefully we grow to an even better place.

“Merely having an open mind is nothing: the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” — G. K. Chesterton

Did you like this? Share it:

Modern Day Software Development: “Embracing Change” – Part 2 of 2

Wednesday, 20 April 2011 12:47 Written by AdventureTech 0 Comments

Last week we wrote Part 1 of our 2-part series on the role change plays in Modern Software Development. If you haven't read it yet, you can do so here: Modern Day Software Development: "Making Change Difficult".

At AdventureTech, we realize that the only constant in software development is change. Because we have a full and deep understanding the role change plays in the software development process, we have fully embraced another common approach to managing software development: AGILE.

Defining Waste

Dictionary.com defines waste as "a useless consumption or expenditure" or even better "a use without adequate return". There is no better example of that than large upfront requirements gathering efforts with the myth of locking down all requirements early on.

Companies claiming to be agile espousing this type of methodology are simply being dishonest with themselves and their customers about who and what they are. The simple and honest reality is that all requirements for a software development effort of any substantive size simply cannot be known upfront.

In an agile world, decisions are made later rather than sooner. The idea behind putting off decision-making until later is that you will have more clarity into what you are building than you do early on. In Lean Software Development, An Agile Toolkit, Mary and Tom Poppendieck describe a concept of waiting until “the last responsible moment” to make decisions. It is at that time that the most data is available to make an informed and educated decision instead of a "guesstimate".

With that in mind, AdventureTech embraces a methodology that breaks a single piece of software into several small functional pieces of software (features) that together make up the end product. We then work toward building each software feature and delivering it to the client "piece by piece", and allowing them to see working software early and often vs. late and all-at-once.

This approach keeps us from breaking out detailed requirements that may never even be built in the long run. Most software developers have seen projects with heavy, upfront requirements phases where as much as 50% of those requirements specified in the beginning never even see the light of day. If that's not waste, we don't know what is!

Change Management

Another common practice for companies not practicing agile is to have large, formal, documentation-heavy change control processes. Software vendors put these processes in place to limit the amount of change clients are allowed once the build effort has begun thereby limiting their risk (and protecting their margins).

At AdventureTech, we embrace a process that allows change but makes it visible to the client. What that means in laymen's terms is that we believe in putting our customers in charge of what we build and how much it costs by the decisions we make together.

Close collaboration with our customers is at the core of a successful agile project. Gone are the days when software developers sequester themselves away from the "distraction of customer interaction" so they can get some "real work" done. In the agile model, the customer and the software developer form a new entity….a TEAM dedicated to buildling software. This model is extremely heavy on trust and visibility with the goal of succeeding together.

While change is much easier in an agile world, that doesn't mean it is not visible or that we are not responsible as a team for the decisions we make. When requirements are changing/growing in an agile project, a good software developer will make that visible to their customer. This allows customers to make whatever course corrections are necessary based on their specific constraints (i.e. time, money, specifications).

Conclusion

Every day, more and more companies are realizing that building software is not like other industries. While nailing down requirements like blueprints for a construction project is possible, it's not the best way to build software in today's world.

According to the Standish Report surveys (1994-2009), 68% of software projects are NOT successful (over time, over budget and/or lacking critical features). The software development status quo is not working and does not deserve to be replicated.

At AdventureTech, we are here to help you learn why agile makes sense for your next software development project and why developing a long term relationship with us will help meet your custom software needs.

If you have questions about agile, leave a comment on this blog or call us today!

Did you like this? Share it:

Category: Agile Practices

The logical conclusions

Technical Debt: When Deadlines Are Met, Bad Decisions Are Forgotten (But Bad Code Lives On)

Lean & Agile : A Panel Discussion

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Question: Is this because full discovery early on is hard to achieve?

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Open Mouth, Insert Software Toolbox

Modern Day Software Development: “Embracing Change” – Part 2 of 2

Defining Waste

Change Management

Conclusion

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets