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.

Pair Programming in an Office Cubicle

I'm really impressed with development teams that pair program, it alleviates a lot of development pressures. Companies like Hashrocket are leaders in pairing practices, In his post Obie describes what's "required" to equip your pair programming environment.

Yeah, all that extra equipment is nice, but what if your team is locked into a typical office cube setup?

• Is it possible to comfortably pair in cubicles?
• What if you can't afford wide desks and a bunch of huge monitors?
• Must pairs be co-located?
• Can a typical office setup accommodate pair programming?

Check out this photo of my most excellent team-mates arranged in typical office cube fashion.


I like these cubes, the low walls make it easy for us to communicate.


Yup, even cubes can be can be conducive to communication. Meet my cube neighbor Rach. See how easy it is for us to converse? So, let's do some pair programming in the cube!


Oh, I hear ya... "how can you share a monitor across a cube?" MS Team Viewer to the rescue! Team Viewer is Microsoft's screen sharing app, it's easy to use, free to try, secure and IP based. Team Viewer faithfully reproduces your screen on your pair's monitor, plus it allows your pair to drive from where they sit with their mouse and keyboard.

Now, you're both viewing the same image and you're conversing face to face, what else do you need?

Ok, I hear ya..."how can my pair see me pointing at their egregious coding error on the screen?" ZoomIt. This is a free utility from TechNet that turns your cursor into a pen, so you can draw on your screen, mark-up and highlight any area on your screen and wipe it clean when you're done

Pairing on two machines is way better than one. Suppose you need to IM a quick question to your stakeholder or check on the progress of the build; your pair can keep stubbing out the new class while you Google up the crazy syntax on that overloaded method. This setup creates the best of both worlds.

Speaking of the world; add a headset, webcam, skype and now you're pairing anywhere...with anyone! So, still think you need a 42" plasma and dual keyboards, forget 'em. Now, go forth and pair.

Value - in a nut shell

A constant flow of new ideas is vital to any growing business.

But what makes an idea great? Which ideas get the most attention? All great ideas take into account the following 3 important factors

1. Resources: What resources (time, money, people) are needed to implement this idea?


2. Risk: What could potentially be lost? What areas of the business become vulnerable? How is the business exposed?


3. Reward: What is gained by implementing this idea? How does the business benefit?

The perfect idea maximizes Reward while minimizing Risk and Resources. Everybody has some good ideas and ideas can come in every shape and size, but the real key to success is to capitalize on Reward while limiting Resources and Risk.

Especially during these lean times low Resource and high Reward ideas are more valuable than ever.

"Strategery!"

Time for an introspective look...

Being vaguely aware of the difference between strategy and tactics I decided to learn more. And in learning more, it's clear that I'm a strategist. Further more, I'm not much of a tactician, and I think it's because I attempt to apply strategy to tactics. Let me explain:

By my nature I'm an observer.

I'm always observing,

In my observations I'm looking for patterns,

Then matching observed patterns to previously discovered pattern,

And using those patterns to determine possible outcomes.

...sounds like typical strategy stuff.

However, observation is a passive activity and successful tactics require action. I keep wanting to apply strategy to tactics and it doesn't work. What's needed to apply successful tactics is execution.

The old Nike commercial says; "Just do it." By contrast my commercial would be "Just analyze it."

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.

The simplest measure of value

Jack also brought back this very simple equation from PO Certification.

Business value = Business visibility