Tales of Agility

Here at The Gartrell Group we use the agile approach to software development because it matches our personalities and seems to work well for us. In this short blog post, I thought I’d share several recent thoughts and passages on the Agile process from the past month.

This first piece has been widely popularized so perhaps you’ve already read it. It’s worth sharing far and wide in my opinion. I assume it’s anecdotal, but it feels quite accurate based on personal experience. It comes from the book Art & Fear by David Bayles and Ted Orland and was copied from here:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Fascinating isn’t it? Reinforcing the spirit of Agile, the teacher inadvertently proved that refinement comes in cycles and that while valuable, specification does not trump implementation. Communicating complexity will require more than just one loooong perfect session.

The second piece has been shared widely as well and more-humorously adapted to the software design process specifically. I chose the version of the comic below given it’s explicit calling out of the problem at hand. Communication.


The more effectively a team communicates, the more productive and efficient they will be. The above is funny because it’s true. We’ve all seen projects that missed the mark by more than a little. What was missing? Communication. Knowing that it can be very hard to document complex systems and business rules, we prioritize communication and iteration to ensure that the design is true. We develop communication devices quickly (aka minimum viable products (MVP)) and frequently (think pots) to enable continuous kinesthetic and mutual interaction with what will become the final product.

Don’t be afraid of failure and keep on potting.

DevTools gushin'

Here at The Gartrell Group, we spend a lot of time building and debugging web maps.  While we do our fair share of architecting and back-end work, for the past few years, we’ve definitely been JavaScripting more than anything else.  In reflecting on how much time we spend in the JS space, I decided to take an opportunity to express my gratitude to our daily companion that is Chrome DevTools.

It all started with Firebug.

An image on the Firebug page…

An image on the Firebug page…

Firebug was like a cool drink of water in the middle of a desert...

15 years ago I needed a better understanding of what was going on under the hood of my web projects and Firebug was pretty much the only game in town… I think Chrome had just barely hit the shelves and my nose was still firmly turned up to the notion of a Google Browser (my how things change). Internet Explorer offered a sort of debugging tool but it lacked usability and functionality (and…it was Internet Explorer).  Overnight, Firebug became my Swiss army knife for monitoring AJAX calls, injecting DOM elements, and reviewing global variables - productivity power-up!!  Prior to browser debugging tools, the only way I knew of to interact with a website was by executing JavaScript typed into the browser address bar (OMFG - it actually worked.).  Since search has overtaken what you submit in the address bar, this terrible parlor trick is merely a memory…

Chrome eventually replaced Firefox for me, due in no small part to the fantastic built-in developer tools; Firebug became part of Firefox, Microsoft improved Internet Explorer’s development tools and web devs across the planet rejoiced.

Writing business software to solve problems like tallying bananas, updating a twitter feed, or integrating your dishwasher into your Alexa network entails a fairly linear development arc with a straightforward problem space.  Web programming on the other hand can be a more spiraling affair involving continuous integration and tedious revision.  The interactive editing allowed by DevTools quickly becomes invaluable and includes a massive host of functionality but beyond that it achieves that most sacred of software goals, it just works.  So much software advertises feature richness and reliability, but so often it fails to deliver. DevTools delivers. Moreover, as heavily as we use it, I get the sense that we’re probably only scratching the surface of what is possible with it.

I was prompted to write this homage after being floored by the ability to browserify some node modules, inject them into a web page, and automate some data retrieval. Again, it just worked.

We at TGG wish to thank the developers and maintainers of Chrome DevTools and the Chrome Browser for increasing our productivity, and the productivity of our clients. Keep making software that just works.