Category Archives: agile techniques

Kent Beck says “No Tests?”

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.


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.

Track Hours?

From Alan (a thread on agile project management forum):

Now as to the why-bother:

1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.

2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don’t know if it varies from week to week. I don’t know how long it will take to finish a project AT ALL.

I am suggesting that tracking hours is but one small wee part of estimation… and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.

Though you can certainly have everyone track hours & tasks to the minutest detail… what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?

See rest of post here:

Tracking Hours for Every Task

Dealing with Old Management Habits

Responding to:

John Hebley said the following on 10/20/08 11:08 PM:

Philippe, Jon

May the force be with you. I was about to rant and rave about incompetent managers etc, but that would be just preaching to the choir.

That is a new topic, if you want to discuss it. How do you work with these, often senior managers, that have no idea what you are trying to do, and insist on applying 1970’s thinking?


I find it very common that many folks (yes, some of these are “older” managers) retreat to the comfort of what they were familiar with in the “good old days”. Probably human nature when confronted with being out of the comfort zone. I have been doing agile development since the early 90s and have been taking unique approaches to solving problems for longer than that. I am familiar with folks who don’t “get it” or who need a preponderance of evidence to be won over.

A partial list of my responses to an “older manager”:

  • I have to suppress being impatient (see personality profile

    below)… You see, for me, many times it feels like battling the

    Flat Earth Society; or the “Gravity Points Up” mentality; or “The

    Ostrich Society”

    • By nature I have always been an early adopter.
    • By nature I am an engineer
    • By nature, I trust, but verify
    • By nature I am impatient to get results
  • When I feel stressed by those that seem to “take issue” with what

    I am trying to do to achieve (largely their) business success, I

    take it as a sign I need to do more educating, show more, explain

    more, assume they have validity in their feelings.

  • I ask them for things they would like to see that would “prove”

    (to them) whatever the particular matter is at hand

  • Funny thing, many times they can’t think of what to ask for, they

    just know “it doesn’t feel right”… Sometimes I find myself

    moving the level of thought “up” for them and I provide ways to

    achieve degrees of “proof” that never before existed at their

    company or in any other project.

  • I am profuse in beating the drums of process, quality, testing,

    automation, and many small bits that make up a high-performing

    team and on-track project

  • I will make uncertainty, variability, and risk more visible to

    combat the illusion that traditional Gantt charts or Work

    Breakdown Structure approaches to managing software feature

    development are better than the way I run iterative development.

  • I will try all sorts of approaches to communicate if at first I

    don’t succeed

  • The project wiki is a huge part of this
    • I blog about the project (“News”)
    • I stand up special pages when I have to address yet another

      “senior management” challenge

    • I ensure as many stakeholders and other managers as needed

      are in the loop and are helping to allow the whole extended

      group to “get it”

  • When it might be “embarrassing”, I keep the education private (and

    when it would benefit all, I make sure the wiki post or blast to

    the development/project mailing list is not tied to the requestor).

  • I work very hard to shelter the team from the details of these

    sorts of “senior management” moments. I let the team know if/what

    folks are “asking”, but I like to minimize those moments that are

    more distractions on the core development trajectory, than helpful.

At the end of the day, I know I am doing my best, often working harder than anyone to achieve the ultimate business goals that the project has been chartered to achieve. I live and breathe the project business goals. I let the chips fall where they may.

For obvious reasons (to me, anyway), in any complex project that I am involved with, there would be no chance of me doing it as fixed-price work. That would compromise being able to respond to the “human” parts of the project and client needs.

— jon

ps: My personal response can range widely, I am sure. Here is the beginning of one (of many) behavioral profiles for me:

Jonathan likes to be forceful and direct when dealing with others. His desire for results is readily apparent to the people with whom he works. He is driven toward goals completion and wants to be in a position to set policy that will allow him to meet those goals. He displays a high energy factor and is optimistic about the results he can achieve. The word “can’t” is not in his vocabulary. Many people see him as a self-starter dedicated to achieving results. Jonathan is aggressive and confident. He is deadline conscious and becomes irritated if deadlines are delayed or missed. He is a goal-oriented individual who believes in harnessing people to help him achieve his goals. He needs people with other strengths on his team. He is often considered daring, bold and gutsy. He is a risk taker who likes to be seen as an individualist. Jonathan may have difficulty dealing with others who are slower in thought and action.

I would advise against that

Many times, we in the technical community are faced with well-meaning users and stakeholders that ask for something “their way.”

My wife and I stopped in a fine Italian restaurant for lunch. Sue ordered a risotto dish, while I ordered a grilled salmon over mixed baby greens. When the risotto was served, the waiter offered to sprinkle fresh grated cheese. I was ready to get a fresh spoonful of that cheese deposited right in my mouth, it looked so good.

Then the waiter turned to me and my “salad” and offered pepper. I blurted out that I would like some cheese. (Sue cringed, as she always tries to remind me that Italian fish dishes should never be served with cheese with seafood. )

Back to the technical point… the waiter was very diplomatic:

“I would advise against that.” he said. “Oh! That’s right, no cheese on seafood! What was I thinking?” “Well, rules are meant to be broken, so you may do that if you like. I would just advise against that.”

He didn’t say I was wrong. He didn’t say I couldn’t have what I had asked for. But he carried a certain authority of being “in the know” and I trusted his judgment.

I hope to use this gentle technique the next time I need to respond to a user’s well-meaning, but “wrong” request. Maybe it will help you out as well.

Talk is Cheap

In the agile usability forum, Steve Gordon astutely observed:

“Making these choices is a business decision that requires balancing strategic and tactical considerations in the specific context.”

i agree. imho, one of the roles we, as software professionals play, is to provide the business with some “cost” information and some potential alternatives. when a specific feature idea comes forth from the business side, we are to provide cost (in terms of effort, schedule, and even downstream ramifications). We can also discuss various variations on a theme. For example, many times the development team might say: “Well, providing X is expensive and would take 6 months. However, we could do Y — which seems like it would achieve nearly the same result — for a much smaller cost, and have it done in one month.”

Talk is (usually) cheap(er) than one-way (non)conversations.

That is, a non-agile “Company A” might simply spit out a new feature set idea in an email. Then, the dogmatic development team spits back a single answer (it will cost X). Business chooses not to go forward. Meanwhile, competitor B implements Y and drives Company A to lose business and go bankrupt.

Or, non-agile Company A accepts excessive cost X. Company B does Y, gets it done sooner and eclipses Company A’s much later release of an only slightly better feature X. Company B makes more money, Company A never recoups the cost of feature X.

Talk is cheap — and that’s a good thing when it comes to working as a team for a common goal. Company A did not have a discussion, and it cost them dearly.

Good Judgment is Agile

a quip from the agile usability forum…

“But I still think that, in the early stages of UI design, in a project where the UI is critical, getting a usable paper prototype, as verified by user testing, is significant progress.”

as an agilist, i would agree.

i tend to run parallel tracks during initial development based on the project specifics. once i have gathered enough requirement details to have a good overview of where we need to go, i might begin some specialized “research” tracks, a.k.a. “spikes”, even as i may be gathering more requirements and building more of the object model. the overlapping activities may be any of these:

  • requirements workshop
  • a spike to work out technical architecture
  • a spike to work out User Experience issues
  • doing anything else in parallel that helps to reduce risk
    • risk of missing important requirement details
    • risk of producing an unusable app
    • risk of producing a non-performant app

The challenge is knowing when to do these sorts of things, and not allowing any single “prong” of the attack to get too far or too deep compared to the others. The purpose being:

  • you often get diminishing returns, you just need to investigate enough to get the 80% mark (for example)
  • you don’t want to waste effort on something that turns out to be obviated by something you discover in another track

It may help you to understand I have a few very closely-held tenets about software development:

  • The key to development is separation of concerns
    • the core is the problem domain built to support the requirements.
    • get this wrong, nothing else in the app matters. nothing.
      • not the UI/UX.
      • not the 5th normal form DB.
      • not the worlds most articulate UML models.
      • not the worlds best cruise-controlled, TDD, 100% test coverage,
      • not the best joshua bloch-/steve mcconnel-blessed code.
    • this core generally transcends UI, database, and even the language chosen to code the app. In other words, the “problem domain” reflects the relatively stable “business” world. I know it sounds trite, but despite all our wonderful software advances from green screen to now, the world of mortgage/insurance/banking has changed little, fundamentally, or relatively.
      • the app is all about the “business” needs
      • the User Experience/UI is a separate thing
      • The persistence is a separate thing
  • Carefully orchestrating the various tasks in parallel using agile approaches that hold dear doing the “best thing possible” given the business & development circumstances, constantly adjusting in a smart way.

it is about understanding risks, managing them, and using the elusive stratagem known as “good judgment.”

RIA as a part of Agile

part of the struggle with conversing on a topic as broad as UX in or outside the ASD loop is one of “size.”

for reasonably “straightforward” features that require UX design, a couple of iterations is usually sufficient to get to a good place. my steps are typically:

  • understanding the basic requirement (e.g., we need to use a special service to look up critical special info from a ZIP code as part of a custom address UI),
  • the domain details (often down to methods/sequence diagrams),
  • some dynamic behavior of how the UI might interact with the domain model/server (after zip is entered, make a server call, get the linked lists of the related objects), and a
  • rough sketch.

When to spawn a separate UX project

if the team senses that:

  • UX is a major and critical aspect of the final product (as something like the iPhone probably was),
  • the design is very complex,
  • “getting it right” will impact greatly on the success or failure of the product,
  • there is a need to explore a handful of design ideas before committing…

well, sounds like you need to have a project to do this effort unto itself.

The UI is Independent of Domain

In general and virtually “always,” while the “UX Big Design” project is underway, the rest of the team can carry on with much of the other part of the system development. The UI — regardless of the complexity or simplicity of the UX design — is rather independent of the server or domain side of the world. So, even tho my project may have a parallel cool UX design component going on with its own features/iterations, i have all of the features still visible in the iterations through what I termed the “Rough UI.”

Whether the feature is surfaced in an ugly, simple UI control world, or a slick Flex/RIA world matters little. The core “back-end” API still needs to function. As the fancy UI components get finalized, they can be connected to the real API one by one.

Soon the ugly duckling UI turns into a beautiful swan.

The Cost of Complexity

In reading this very nice post from Manoel Pimentel Medeiros, I am reminded of another value I ascribe to simplicity — “quick-and-dirty” can be a valuable technique.

Many times, when faced with some very complex issues in my projects (usually surrounding integration with bizarro other systems), I strive to have developers take a very simple approach at first. Sometimes these approaches seem like hacks, inelegant, and the exact opposite of what I normally practice. Sometimes I can tell it is hard for the developers to do this “ugly” work. (Maybe they fear I will leave the ugly hack in place .)

However, this is a technique I use when the route is not clear, or when there are viable alternatives from which to choose. Or if we are probing for the right solution and are not confident if the chosen solution will work. So, instead of designing a more complex and elegant “correct” solution, I do the simplest thing. Maybe it means dummying up the data to achieve the effect. Maybe dummying up some objects. Hard coding. Passing in a fixed XML file to test the new format versus changing the code to generate it that way.

By choosing a simple solution *now*, the value is that we can get to evaluating the results and downstream impact of our ideas sooner rather than later. Once we determine that our solution will work, then we go about implementing it correctly. At times, though, we discover that the idea didn’t work as expected. So off we go to look for another solution.

So, simplicity can also be very useful when trying to quickly and cheaply determine the best course of action in creating a viable solution to some aspect of a problem you face.