How about a simpler Functional language? Maybe AppIgnite?

I think nearly every programmer has written a game. Why? Because dev's tend to be gamers...they are "game domain experts." What a Dev knows is easiest for them to program. Like my friend, who released a time tracker app, he was a contract programmer and he needed a time tracking solution so he wrote it and sold it to others. It was written because it was in his head.

Think of all the niche apps out there that could be written, but will never be written because the "domain expert" is not a programmer. Ideally, there would be a "functional" language intuitive enough for anyone to get started, right-out-of-the-box.

And when I say "functional" I'm not referring to the myriad of expressive languages that have emerged, I envision something visual, less syntactic, but still extensible, so that the idea-man could mock up a working app and possibly team-up with others to extend the solution.

I'm really excited to hear more about AppIgnite. Although it's not yet ready for prime-time I think Jason is on the right track. I learned about AppIngine on Techzing (an outstanding Podacast, where Jason and Justin share everything of interest from the world of entrepreneurial dev's). They both have home-grown commercial apps and share their daily thoughts and experiences through the Podcast.

I know the dream of a "programmer-less-programming-language" has come and gone in many forms, but listening to Jason expound on AppIgnite's design I'm really looking forward to getting my hands on it. This has the potential to be a productivity "game-changer" for everybody who has an idea for an app, but nowhere to start.

What If Congress Adopted the Agile Manifesto?

I wish Congress was full of Agile Practitioners (Poppendieck for Senate!). Thinking about this I wondered how the process of passing Heath Care would look when judged through the lens of the Agile Manifesto. Below is my retrospective of HR3200.

The Agile Legislative Manifesto:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable legislation.
...9 months and 2074 pages, ummm I don't think so...

2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
...Congress did implement some "competitve advantages" for customers like Louisiana ($100M in exemptions), California ($300M in Medicare payments), AARP received $18M in stimulus money and the Unions got an exemption for "Cadillac" health plans. However these "advantages" inure to the benefit of constituencies, some stakeholders may disagree.

3) Deliver working legislation frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
...Fail

4) All Parties must work together daily throughout the project.
...Fail again, 'nuff said

5) Build legislation around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
...There have certainly been a lot of "motivated individuals" working on this but not a lot of "trust" and "support."

6) The most efficient and effective method of conveying information to and within a legislative team is face-to-face conversation.
...There appear to have been many closed-door "face-to-face conversations," unfortunately many essential stakeholders were excluded, the entire process could have benefited with some transparency, courtesy of C-span.

7) Working legislation is the primary measure of progress.
...No measurable velocity yet.

8) Agile processes promote sustainable development of legislation. The sponsors, legislators, and users should be able to maintain a constant pace indefinitely.
...The political machine has chewed up and spit out everybody involved. "Sustainable development" has yet to be achieved.

9) Continuous attention to legislative excellence and good design enhances agility.
...Maybe this can be included in a future iteration
.
10) Simplicity--the art of maximizing the amount of work not done--is essential.
...I think Congress skipped this step. Oh well, it was the only "essential" step.

11) The best architectures, requirements, and designs emerge from self-organizing teams.
...All teams were "self-organized" unfortunately they organized down party lines.

12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
...Mid-term elections could make for an interesting retrospective.

Here at Devlink in Nashville

So far the best session has been the informal experts panel that was held during lunch. Some gems came from the guys on the panel.

After 33 years of changing technology knowing a methodology and language are secondary. More valuable skills are are;

• the ability to solve your problems...agiley
  
• understanding business domain problems and mapping them to the code (ie: developers are no longer coding in a silo, you've got to understand the solutions's "what" and "why")
  
• (not really a skill, but I loved this...) subersively sneak Agile principles into an organization (a great story about a continuous integration server hidden under a developers desk)

Really cool stuff.

Adaptive Sampling, you're doing it and don't even know it.

Alistair's article of adaptive sampling make a good point about quality not needing to be uniform:

"... First of all requirements statements aren't requirements, they are only placeholder tokens for [need-solution] pairs. Secondly, the system doesn't have a single quality requirement, the quality characteristics vary by [need-solution] pairs. We can save time and money on the project by examing each "requirement" (or wish, or user story, or backlog item) individually, and working out what the appropriate level of effort will be needed at that one spot. We can save time and money in that endeavor by using [this] adaptive sampling idea and breaking the work into areas, those with similar quality needs..."

A great quote

I found this valuable quote in the Introduction to the Eclipse PPT. It's by Alfred North Whitehead, a 19th Century British mathematician, logician and philosopher.

"...by relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect, increases the mental power of the race."

No more "done"

I dislike the word "done" because the defenition can be so subjective. For instance, my idea of "done" may not be your idea of "done." Instead of asking "...is it done?" I would prefer we ask "...does it perform?"

The shortest distance

Is this totally Lean? You don't know what "you don't know" until you know it. So minimize your reliance on guess work. Use Occam's Razor and push forward. Do something, measure it, revise your model based on the new metrics, rinse and repeat. Keep speculation at a minimum.

Deep thoughts (better than Jack Handy)

This is very deep and might be cool (if it can be transliterated from "theoretical" to "actionable"). Read this link.

Contained is this quote; "Remember a rule of system thinking is to understand the whole in favour of the parts. So look at the situation and ask your self how are the different smaller level wholes related to make the bigger level whole."

Refuting Lean?

How come most bloggers trying to refute Lean concepts and Agile methodologies sound like Durwood Fincher?

Requirements gathering

Some dude says this here

"If you believe that customers are responsible for defining their requirements, you will primarily employ interviewing and 'elicitation' techniques to obtain requirements. The definition of elicit is 'to draw or bring out or forth; educe; evoke.' The customer often perceives this as 'extraction' or even 'extrusion.' Using this method, you are at your customers' mercy--you know only what they tell you. Requirements will almost certainly be incomplete. Even if customers appear unable to define their requirements, you may believe that they are not only able to do so, but that they are responsible for doing so. You may believe that the correct elicitation tools and techniques will achieve success."

It sounds like he's saying customer's don't know what they want. I agree that is frequently the case. Showing them "concepts" can help them see what a potential solution looks like.

Fail Faster

“I have not failed seven hundred times. I have not failed once. I have succeeded in proving that those seven hundred ways will not work. When I have eliminated the ways that will not work, I will find the way that will work.” - Thomas Edison

Don't forget to leave room for the failures and leverage the development process so you fail faster

Start quick fail faster (be lean)

Kent Beck says this (Tyner Blain blog):
"...customer’s don’t know what they want, we should start building stuff right away, with the expectation that by seeing tangible results (good or bad), they will have epiphanies about what they really want. This approach treats requirement extraction as an emergent process, like strip-mining. With each new layer of mining, we unearth a new set of hidden requirements."

Build first ask questions later goes too far. I think we can prototype (hi or lo-fi) and show customers a vision of what they've requested. From that we can help them discern what they need. This makes me recall a session from Agile 2007, when we demonstrated functionality by each person playing a different role (replicating the technology) and users interacted with the interface. It made for fast process adjustment to user feedback.

Two soft concepts

This may be an interesting article on ROI. ROI is both hard and soft. For an automation hard costs could be a savings of man hours...very calculable and very predictable. Soft ROI numbers should be discounted 60% to 90% according to Tom Pisello.

I jacked this from the Tyner Blain blog: It's where another soft concept is introduced, the concept of utility:
"Agile software proponent Kent Beck argues that people don’t know what they want when you ask them. There may be some scientific support for his argument based on some research cited by Barry Schwartz in The Paradox of Choice: Why More is Less. Schwartz references psychologist Daniel Kahneman’s studies of how people remember events, in an explanation of how people measure and assess utility. To sum up, here’s the flow of events: A person has an experience, and recognizes some satisfaction from it. This is known as experienced utility. This is the function that economists reference when defining the indifference curve. When remembering the event later, a person will remember incorrectly. Their memory of their level of satisfaction is their remembered utility. The problem is that the remembered utility never precisely matches the experienced utility. This poses an interesting problem. Even if we find people who have experienced exactly what we’re trying to analyze, they will be unable to correctly tell us how much satisfaction they derived in the past."

Here's the Tyner Blain blog conclusion:
"The value of a requirement or feature is a function of user satisfaction and the financial benefit of having that requirement implemented. The user satisfaction can not be quantified in advance because we have no framework for reliably predicting satisfaction - even based on past experiences. "

That is very interesting, as much as user's demand certain features without being able to provide a cost justification for their demands.