Feature Lifecycle Analysis with PivotalTracker

Can you trust your agile planning process to deliver the best result over time?

In an ideal world with a well-balanced and high-performing team, theory says it should all be dandy. But what happens when the real world sticks it's nose in and you need to deal with varying degrees of disfunction?

Feature Lifecycle Analysis is a technique I've been experimenting with for a few years. The idea is to visualise how well we are doing as a team at balancing our efforts between new feature development, refinement, maintenance and ultimately feature deprecation.

If you'd like to find out more, and run an analysis on your own projects, try out the Feature Lifecycle Analysis site. It includes some analysis of two real software development projects, and also a tool for analysing your own PivotalTracker projects.

As always, all notes, schematics and code are on GitHub.

On "random" CI failures

I closed a bug yesterday that's been kicking around for almost a year as a sometimes fails on CI but no-one can figure out why frustration.

Sooner or later you'll hear someone suspect it must be a problem with CI. Which is ironically funny in a shoot-the-messenger kind of way!

Thankfully our "CI issue" turned into a for-real bug. In short, the code involved many classes with near 100% test coverage. It had been read and re-read and everyone would swear there's no way this could fail.

No, of course we were wrong. The bug was basically a conspiracy of two bits of code in two very different places:

• a record validation that ensured field1 was not the same as field2
• a data collection routine that could be configured to filter/replace sensitive values with a random ** string: ["*" * rand(4..10)]

And you can see where this leads: our problem was filtered data ending up by obscure and circuitous means in field1 and field2 ... with a 1 in 7 chance of the record validation failing (never happens on our machines of course). After that it was an easy fix.

So once again we learn the lesson:

If CI say red but we can't figure out why, "must be a problem with CI" is 99.999% the wrong answer. It just means we haven't found the bug yet.

I've seen this scenario play out a dozen times in as many years, and CI was always right;-) Since it keeps cropping up, it made me think about how to best knock these on the head. Five things:

start by assuming there is a bug until proven otherwise

It's too easy to give up, find scape-goats or "magic" explanations otherwise.
Take heart in the fact that if you assume CI is right, the odds are on your side.

put a canary in a coalmine

When we first encountered this issue and failed to find the root cause, we added code to catch the "this is about to fail in that unexpected way" situation and log/report appropriately.

So while the ticket got iced, it's been that "canary" that keeps dying in order to keep the issue alive! So when it died again yesterday, it was a painful reminder to get to the bottom of the issue once and for all.

finding bugs .. is like looking for your keys

Always found in the last place to look. So when you've honed in on the code you think is failing, studied it upside down, left to right, and still can't find the issue .. maybe it's time to consider you might be right. Throw out that hypothesis, pull back and fan out instead.

treat random errors like a lottery

If errors happen infrequently, reproducing them is like trying to win the lottery. The more entries, the better your chances.

So don't run tests a few times, run them millions of times if you have to. Computers are good at this. That's how I diagnosed this latest issue while tweaking logging and the test itself. Bash away:

for (( ; ; )) ; do
  rspec spec/that_wierd_spec.rb 
  if [ $? == 1 ] 
  then 
    echo "JACKPOT!" 
    break 
  fi 
done

random failures ... might really be random

This sounds so simple that it's easy to overlook.

If things fail randomly .. it only takes a few moments to search the code to see if anything is using something similar to a random function.

Could it be possible that random failures and the use of rand() might be related?!
May be not, but if they are, that's a cheap win!

LittleArduinoProjects#018 The Fretboard - a multi-project build status monitor

(blogarhythm ~ Diablo - Don't Fret)

The Fretboard is a pretty simple Arduino project that visualizes the build status of up to 24 projects with an addressable LED array. The latest incarnation of the project is housed in an old classical guitar … hence the name ;-)

All the code and design details for The Fretboard are open-source and available at fretboard.tardate.com. Feel free to fork or borrow any ideas for your own build. If you build anything similar, I'd love to hear about it.

2013: Time for web development to have its VB3 moment

(blogarhythm ~ Come Around Again - JET)

And that's a compliment!

Wow. This year we mark the 20th anniversary of the Visual Basic 3.0 launch way back in 1993.

It's easy to forget the pivotal role it played in revolutionizing how we built software. No matter what you think of Microsoft, one can't deny the impact it had at the time. Along with other products such as PowerBuilder and Borland Delphi, we started to see long-promised advances in software development (as pioneered by Smalltalk) become mainstream reality:

• finally, Rapid Application Development that really was rapid
• simplicity that put the development of non-trivial applications within the realm of the average computer user. It made simple things simple and complex things possible (to borrow from Alan Kay)
• development environments that finally did the obvious: want to build a graphical user interface? Then build it graphically (i.e. WYSIWYG), and build a complete client or client-server app from a single IDE.
• an event-driven programming model that explicitly linked code to the user-facing triggers and views (like buttons and tables)
• perhaps the first mainstream example of a viable software component reuse mechanism (improved and rebranded many times over time: ActiveX, COM, .NET)

In its day, Visual Basic 3.0 was variously lauded (by non-programmers who could finally make the app they always wanted) and loathed (by IT professionals shocked at the prospect of ceding control to the great unwashed). Interestingly, Visual Basic succeeded *despite* the language (BASIC, probably the most widely derided language of all time. Or perhaps it shares that crown with COBOL).

The party didn't last long however, as by the late 90's the internet had fundamentally changed the rules of the game.

VB, PowerBuilder and the like suffered from an implicit assumption of a client-server architecture, and were not prepared for a webified world. They didn't (all) disappear of course, with Visual Basic in particular finding a significant role as Microsoft's mainstream server-side language, and it lives on in Visual Studio. Yet it lost it's revolutionary edge, and had to be content to simply fit in as an "also can do in this language" alternative.

Web Development - a case of one step back and one step forward?

You would think that over the past 20 years, web development would have been able to leap far ahead of what was best practice in client-server computing at the time.

We have certainly come a long way since then, and many advances in practice and technology have become de rigueur. Here are some examples that would not have been considered normal by any stretch in 1993:

• Reliance on open standard protocols at every tier: from client to server, server to database and messaging systems
• Global, well-known repositories of shared, reusable code (Github, Rubygems .. and let's not forget grand-daddy CPAN)
• Version control. There is no argument.
• Automated testing tools and continuous integration.
• Open source is mainstream, and even preferred in many contexts.

Yet it is also salutary to reflect on some of the great innovations we saw back in 1993 that have yet to be re-invented and re-imagined successfully for the web.

I am thinking in particular of the radical productivity that was possible with the event-driven, WYSIWYG GUI programming model. It certainly hasn't gone away (take xcode for example). But why is that not the leading way of building for the web today? After all, the web is graphical and event-driven. A perfect fit one would think.

It has perhaps been the very success of the internet, and the rapid unconstrained innovation it has enabled, that has in turn inhibited major advances in web development.

Those that have come close (such as Adobe Flash) have ultimately failed primarily because they did not embrace the open standards of the web. And others, like Microsoft Visual Studio and Oracle JDeveloper have remained locked in proprietary silos.

On the whole, we still work at levels of abstraction that are no higher, and many times lower, than those embodied by the best tools of 1993. It is, after all, very difficult to build abstractions over a foundation that is in constant flux. And with highly productive languages and frameworks at our disposal (like Ruby/Rails), it makes complete sense for many - myself included - to actively spurn graphical IDEs for the immense flexibility we get in return for working at the coding coalface.

The Tide is Turning

Once the wild west of hackety scripts and rampant browser incompatibilities, the building blocks of the web have been coalescing. HTML5, CSS3 and leading browser rendering engines are more stable, consistent and reliable than ever. Javascript is now considered a serious language, and the community has embraced higher-level APIs like jQuery and RIA frameworks such as ember.js and backbone.js. Web design patterns are more widely understood than ever, with kits like bootstrap putting reusable good practice in the hands of novices.

On the backend, our technology stacks are mature and battle-tested (LAMP, Rails). And we have an array of cloud-ready, open source solutions for just about every back-end infrastructure need you can imagine: from BigData (Hadoop, MongoDB ..) to messaging (RabbitMQ, ØMQ ..) and more.

My sense is that in the past couple of years we have been edging towards the next leap forward. Our current plateau is now well consolidated. Yet despite efforts such as codecademy to open up software coding to all, web development remains as complex as ever. To do it well, you really need to master a dizzying array of technologies and standards.

Time for Web Development to Level Up

What does the next level offer? We don't know yet, but I'd suggest the following as some of the critical concerns for next gen web development:

• a unified development experience: the ability to build a full-stack application as one without the need for large conceptual and technological leaps from presentation, to business logic, to infrastructure concerns.
• implicit support for distributed event handling: a conventional mechanism for events raised on a client or server to be consumed by another client or server.
• event-driven GUI development: draw a web page as you want it to be presented, hook up events and data sources.
• it is mobile: more than just responsive web design. Explicit suport for presenting appropriately on the full range of desktop, tablet and mobile devices
• distributed data synchronisation: whether data is used live on a web page, stored for HTML5 offline, or synchronized with a native mobile application, our tools know how to distribute and synchronize updates.
• (ideally) let's not have to go back to square one and re-invent our immense investments in standard libraries and reusable code (like the extensive collection of ruby gems)

Do we have the perfect solution yet? No.

But we are starting to see enticing inklings of what the future may look like. Perhaps one of the most compelling and complete visions is that provided by the meteor project. It is very close.

Will meteor streak ahead to gain massive mid-share and traction? Or will an established platform like Rails take another giant step forward? Or is there something else in the wings we don't know about yet?

It will be an interesting year. And if the signs are to be trusted, I expect we'll look back on 2013 as a tipping point in web development - its VB3 moment.

Do you think we're in for such a radical shift? Or heading in a different direction altogether? Or will inertia simply carry the status quo... I'd love to hear what others think!