I just finished the 37signals book “Getting Real” yesterday and wanted to share some thoughts. We bought a 10-user license the day it launched to give each one of the members of the G7 pilot program. Having followed the 37s blog for well over a year, I like their philosophy and we knew this would be a good distillation of their principles and a good way of indoctrinating this philosophy in our own peeps. First if you are in the web application development industry and do not know who 37signals is, you are some kind of ostrich – these guys are the success story of a small business. They were a tiny usability-focused design firm a few years ago that stuck to their guns, kept lean and focused on simplicity. They now arguably have the most influence of any sub-10-person company in web development. They “scratched their own itch” by productizing Basecamp, a tool they had created for internal use of managing the development of their own projects and have turned it into a massively-popular solution for collaborating on projects. They have a no bullsh*t approach to everything they do that is so refreshing and have near-religious following on their blog Signal vs. Noise in terms of the loyalty of their readers. They have created a few other products like Backpack, Tada List and Campfire all of which are interesting for their interface design but none as popular as Basecamp (we’re using Basecamp in G7 in conjunction w/ Trac & Subversion to manage our projects). So enough of the ego stroking, overall impression of the book:

Get it. It’s cheap ($20) and it’s available instantly in pdf. It’s a quick read and while you may find no single piece of mind-blowing info that revolutionizes the way you do things, it’s a great way to assess and tune your own philosophy towards software development. They have a minimalistic style and are very much consistent with the AGILE philosophy of rapid iterations and getting a barebones working application developed quickly and in the hands of real people so you can get empirical feedback to guide the development of the product. The book covers the full cycle of research, development, testing and deployment and addresses aspects of application development and design. About 20% of the entire text is peppered with words of wisdom from heavy hitters like Joel Spolsky (Fog Creek), Seth Godin (Purple Cow) and Derek Sivers (CD Baby). It’s a quick read (maybe half a day if you do nothing else). The particular points I found interesting:

On having an enemy – this may sound counter-intuitive – we should avoid having enemies right? But when you’re developing a product, it’s helpful to identify the ones in your space that you hate – it helps you crystallize the essence of what your product will NOT be, how you differentiate it from the existing options and helps galvanize your staff with a mission. You obviously can’t focus exclusively on trying to beat competition, but having an “enemy” to reference makes the game more fun. Their thoughts on “tell a different story” are very much in line with the ideas espoused in the Innovator’s Solution on not picking a fight you can’t win. If your competitors tout feature robustness, go after simplicity. If they flaunt their impeccable support for every browser since Netscape 1.0 – go after responsiveness, a snappy clean interface and only support firefox and safari…

On emergence – Their thoughts on API’s facilitating emergent behavior echo our own at Grid7 – the more you can expose the functionality of your applications outside of the visual interfaces which you conceive, the more you open up the door for others to remix your app, build on top of it and take it a direction you hadn’t imagined when making it. Even though it’s not listed on our G7 homepage, we’re spending the majority of our time right now developing an extremely forward-thinking approach towards how data like job postings, book reviews, events and anything structured will be shared in the future. It involves structured blogging and microcontent and it’s the brainchild of my partner Kimbro Staken. You can read more about this whole initiative from the “tag” page of Grid7 here.

On where the real gains are – This an extremely insightful paragraph from p. 50 and it’s something I’ve known but haven’t seen it expressed anywhere as eloquently:

The best designers and the best programmers aren’t the ones
with the best skills, or the nimblest fingers, or the ones who can
rock and roll with Photoshop or their environment of choice,
they are the ones that can determine what just doesn’t matter.
That’s where the real gains are made.

This is so true- think about all the time you spend learning new facets of a language or the latest ajax widget to make a form work 1% better than how it does now. All this effort to add more flare would be better spent pruning what’s already there and delivering a more stripped-down, intuitive version that lets the user achieve their goal more simply.

On team size and distributed decision-making – this is another great paragraph and is literally at the heart of Grid7 (the 7 originally meant no team above seven people):

As projects grow, adding people has a diminishing return. One of the most
interesting reasons is the increased number of communications channels. Two
people can only talk to each other; there’s only a single comm path. Three
workers have three communications paths; 4 have 6. In fact, the growth of links
is exponential…Pretty soon memos and meetings eat up the entire work day.
The solution is clear: break teams into smaller, autonomous and independent units to reduce these communications links.

On the value of enthusiasm over skill – I can’t stress this enough – I would way rather have someone who is stoked about learning and has an idea they’re passionate about vs. having an elitist recluse who may be the best programmer in the world but has a condescending attitude towards the others on the team. What you know at any given time in our industry is not nearly as important as your ability to adapt, how well you can learn to learn and your passion for what it is you do. I said it in my talk for Refresh the other day, “of the six questions involved in any project- the what / where / when / how / why / who, if you can get one and only one right- fix the WHY solidly in your gut and the others will find a way to resolve themselves.”

On creating prototypes before code – Amen. Before you write a line of application code you should have already sketched out the screens from the app and the flow of the site so you know how it will work. Next step is to translate these into a clickable prototype so the people using it can see what’s involved and provide feedback that will invariably alter the design of the application and hence the code that you would have already written. I did this when first starting the ABC extranet project and it proved to be wildly helpful. I mocked up a wireframe initially using paper and then converted it to a digital version using Adalon, from that I was able to generate this HTML wireframe which I went over with the client and refined until we had all the screens accounted for. Next I threw together a clickable HTML prototype of that wireframe (no logic, hardcoded, CSS from another site since it would be changed eventually anyways) so the client could see exactly how it would work. This is apparently the exact process 37s uses which is encouraging and validates how we are approaching development.

Interesting byproducts of this tactic they pointed out that I had never considered were the improved vision/enthusiasm of the developer, the ability to make better estimates on time/cost and the compass function it served in guiding the development effort. Read this paragraph:

Once the html mockups were completed, we approached our developer,
Scott, with the idea for Blinksale. Having most of the ui designed up front
was extremely beneficial on several levels. First, it gave Scott a real vision and
excitement for where we were going. It was much more than just an idea,
it was real. Second, it helped us accurately gauge how much of Scott?s effort
and time it would require to turn the design into a functioning application.
When you?re financially bootstrapping a project, the earlier you can predict
budget requirements, the better. The ui design became our benchmark for
the initial project scope. Finally, the ui design served as a guide to remind us
what the application was about as we progressed further into development.
As we were tempted to add new features, we couldn?t simply say,Sure, let?s
add that!? We had to go back to the design and ask ourselves where that
new feature would go, and if it didn?t have a place, it wouldn?t get added.

On the choice of languages and how it affects the developers you attract – I’m well aware of all the productivity-enhancing elements of RoR for doing web apps but something I had not considered was the point they made about how the choice of language/platform in creating an application to some extent determines the mentality of the people that will be working on the app. Think of the various choices out there (php, asp, cf, jsp, asp.net, ruby, python, perl) – now think of the stereotypical developer for each language and how you imagine them. I won’t label any of them (even though stereotypes contrary to opinion are useful for making decisions) – there is variation within each language but in general, you hire a java programmer and you can expect different java programmers to see the world in similar ways, same goes for php, same goes for Ruby. They point out the valuable insight that choice of language should not solely focus on variables of performance, scalability, learning curve, etc – but should also take into account the “philosophy of the developers that work in this language” variable.

On code debt – Just reiterates the importance of refactoring in building an application iteratively. You make concessions along the way, calculated tradeoffs in the interest of getting working software earlier but if you let the “broken windows” pile up then you can bankrupt your application in code debt by having many tiny shortcuts lead to poor morale and bugs.

On reaching mavens for a successful launch – Malcolm Gladwell calls them Mavens, Seth Godin calls them Sneezers, the guy we rent office space from calls them Igniters – whatever. The point is if you’re launching something new and trying to get it to “tip” and cross that threshold of adoption where it spreads on its own, you need to focus on things that empower the alphageeks to spread the word more easily. This includes educational pro-bono stuff, spiffy features that people talk about but are still consistent w/ simplicity of the app, and mostly by focusing on creating something valuable for a niche of people. A market is by definition “a group of people that will potentially buy your stuff and reference each other.” This trait is key and 37s recognizes perhaps better than anyone else how to drop teasers on their blog and create a loyal following. Companies that are now paying employees full-time to simply write blogs that regurgitate the marketing messages from their websites are _completely_ missing the boat on how to reach mavens.

On their philosophy of karma, teaching and “pay it forward” – couldn’t agree more- this is at the heart of Grid7 and we are committed to bubbling up the lessons we learn in our experiments back to the community that supports us. Whether you consider this type of effort purely altruistic and karmic or as a pure, calculated mechanism for getting exposure for your stuff, it’s effective. Either way it’s something we’re committed to and are already doing to some extent by exposing our internal “tagging” of topics of relevance on the G7 site.

On ideas vs. execution – spot on. We’ve said it before and I’ll say it again here “ideas are a dime-a-dozen, it’s the execution that matters in the end.” When people express skepticism at sharing their ideas on the Grid7 application or companies seeking VC investment try to have their potential investors sign an NDA prior to sharing info- we say “bleh.” You can have the greatest idea in the world with poor or zero execution and it translates to nothing. Conversely, you can have a mediocre idea with enlightened execution and it’s definitely worth something just for the way in which its implemented.

I’ve been reading quite a bit lately and plan to share thoughts on some of these other works when time permits:

• Guy Kawasaki – Art of the Start
• Seth Godin – Purple Cow
• Jim Collins – Good to Great
• Ewing Marion Kauffman Foundation – Fasttrac TechVenture
• Rhonda Abrahams – Simple Business Plan
• Thomas Pender – UML Weekend Crash Course
• Dave Thomas – Agile Development with Rails

© 2005 Lights Out Production – All Rights Reserved Worldwide

First off, his name is pronounced “Coh-burn” so let’s just get that out of the way now ;-) I finished Agile Software Development tonight and wanted to give a book report here while it’s still fresh to edify some of the points that resonated with me. This will probably be a lengthy post but it’s ripe with good concepts for anyone who manages a team of developers.

The term “AGILE” refers to a style of development that was coined by a committee of seventeen software architects in 2001 at a summit in which they drew up a document they named The Agile Manifesto. It proposed a value system that encouraged certain activities over others in the pursuit of creating flexible, well-constructed software. While Cockburn’s book is relevant to anyone involved in the software development process (engineer, QA person, manager), it probably makes more sense to be digested by a team lead and disseminated to the other developers. With so much reading to keep up with on various techniques, methodologies and languages, a programmer in a team would be better served by devoting her “extracurricular cycles” to material with more tangible, immediate rewards and receiving this type of abstract, work-style advice second-hand via a senior developer. If you’re a lone-wolf developer you may not find this book useful at all but if you deal with other developers in any capacity (internal or external to your organization), it contains some valuable lessons. In short, it gives a holistic, high-level overview of the qualities of methodologies and environments that are used by successful teams. And this is the strongest feature of the book: the fact it is entirely rooted in real experiences. It makes ample use of non-fiction anecdotes to make concepts more memorable and it draws heavily upon hundreds of interviews with real teams that deliver real software under real deadlines. The theories conveyed in technical books can sometimes be refined to the point of “PhD purity and correctness” yet be impractical in application. Cockburn instead offers “blunt, field-tested tools” that are actually getting things done everyday on the front lines of software development. Here are the main takeaways I extracted from this book:

1. Agile Manifesto – as short and simple as this document is (read it – 15secs), it has a profound message- basically, when push comes to shove, delivering good software under deadline is the ultimate goal, good communication amongst a team trumps process and documentation every time, and the only thing consistent across all projects is change and therefore your development style had better be the flexible reed and not the brittle stick when it comes time to deal with change. This manifesto sets the tone for the entire book, the chapters are filled mostly concrete practices that support the Agile manifesto.

   My Takeaway – Prior to buying this book I had heard Alistair
   speak on ITconversations.com . He struck me as being very practical-minded and not high & mighty on theory (which I liked). Having worked informally under both styles of development, I agree with the main values of Agile for being adaptive and goal-focused rather than process-oriented. Agile encompasses a bunch of formal styles like XP, SCRUM, DSDM and others – the tenets are very similar in all though. I especially related to a story about a team that was given strict requirements and micro-managed on the process and documentation required and they ended up ignoring orders and doing it the way they knew it needed to be done in order to get it delivered on time. As so often is the case for developers, you juggle what the client “tells you they want” vs. what you know they truly need and when pressed to favor one over the other, you have to diplomatically choose the latter and make it look like you choose the former.

2. “Microtouch Intervention”: big results from small changes in each member – This is not rocket science but enacting a very small change in each person of a large team can yield massive results with very little effort. It’s the idea that if the project as a whole is like a giant boulder that each team member is trying to move in a certain direction (towards project completion), the vector of force for each person is always somewhat misaligned from the desired direction such that people end up inadvertently wasting some amount of energy pulling against each other. Any steps that can be taken to conserve this energy by: a) communicating the intended direction more clearly b) revealing to each participant their actual vector of pull or c) producing a more compelling reason for people to pull towards the goal, will ultimately yield major gains.
   My Takeaway – This positive effect of this concept is obviously amplified in larger teams. Conversely, the larger the team, the easier it is to dodge responsibility and the more inertia that a stationary group will have. I’m a big proponent of this idea of “paint the vision clearly and then get out of people’s way.” I’ve always thought that energy expended cultivating the enthusiasm and passion of a group is a good buy (ie. if you can get the “WHY” part firmly planted in people’s hearts and minds, the “WHO WHAT WHERE WHEN HOW” questions will find a way to answer themselves). Cockburn validates this notion with a wonderful story from Dee Hock of Visa (second section from the end) and how this type of laissez faire leadership and simple microtouch intervention established a virtuous circle amongst his team and enabled them to successfully deliver a complex system under an ambitious sixty-day deadline. Just read this sentence- “Leaders spontaneously emerged and reemerged, none in control, but all in order. Ingenuity exploded. Individuality and diversity flourished. People astonished themselves at what they could accomplish and were amazed at the suppressed talents that emerged in others.” That’s the flavor of a team operating at peak performance driven by intrinsic motivations from within and that’s what you want to engender.
3. “Erg-seconds” – the energy/time required to transfer important info
   The idea of “erg-seconds” is an analogy Cockburn makes between the transmission of critical information in a project environment and fluid mechanics, or the dispersion of gasses and liquids in a container. In a workplace at any given time there are “convection currents” of info that are venting info like geysers amongst the team members. Anything you can do to narrow the distance this information must travel to reach the necessary recipients pays off exponentially in progress, morale, fewer errors, etc. Mole-meters/sec is the metric used in the realm of fluid mechanics, but that unit does not directly translate over since distance traveled is not the key factor whereas “time necessary to achieve clear communication” is. The optimal situation is to have the people that require the most back-and-forth communication sitting in the same room so they can tap each other for help and overhear and interject when they have valuable advice to contribute. Overkill of this setup creates what Cockburn calls “Drafty cubes” or too much interference with irrelevant info bombarding the programmer. Like anything it’s a balance that must be optimized. Moving further down the continuum of proximity, adding cubes, walls, floors, buildings or even separate geographical locations into the mix gradually introduces more and more friction that adds “erg-seconds” to each interaction in a project and (like we determined in #2) gets amplified in larger teams.
   My Takeaway – This is a very valuable way of thinking about the flow of info on a project. Being a solo consultant, I encounter situations where project delays get compounded by unnecessary “erg-seconds” on interactions not within my development team (of one), but when there are multiple entities involved as clients, and especially when there are tiered teams in each entity. I generally mitigate this problem by occasionally working onsite to reap the benefit of some of the “osmosis” and “convection currents” Cockburn mentions. There is admittedly no substitute for face-to-face interaction- body language, tone of voice, gestures, proximity cues and interjective feedback are lost or hindered when communication occurs via any other method. Neglecting the value of being there to absorb the situation from time to time is a mistake. I have explored the idea of off shoring discrete portions of my projects lately but this concept warns that this geographic dispersion of team members might magnify the “erg-seconds” effect on even simple tasks to the point where it defeats the utility of off shoring I will have to re-analyze the tradeoffs with an eye towards how this effect could be nullified.
4. “Teeing up work” to the bottleneck player
   If we think of software development as an ongoing game of interactive cooperation and communication as Cockburn wishes, then the principle he espouses “#7 Efficiency is expendable in non bottleneck activities” should take care of itself. It’s the concept that if you have say five cooks and one delivery person in your pizza joint, the driver is the bottleneck and your cooks had better “tee up” those pizzas by double-checking that the orders are correct, printing and verifying the directions, perhaps calling when the directions are unclear and making sure the boxes are pristinely stacked in their warming sleeves on the counter for the driver when he/she shows up.
   My Takeaway – Again, I don’t encounter this problem as much since I am solo- every time as the sole developer, I’ll be the bottleneck. The idea that occurs to me though is that I need to utilize the workers in the client’s company better if they can be at my disposal. In even the “best-packaged” project there is probably some added level of prep-work and optimization that can be done to “tee up” the materials for execution. Decentralizing these efforts and pushing as much of this type of activity to the client’s side definitely bides me more time to allocate to activities for which I truly am the bottleneck, plus it has a by-product of #3 and getting some convection currents working to my advantage.
5. The right amount of documentation: light but sufficient
   So there are two goals in this ongoing game of invention and communication- 1) execute well on the current iteration 2) set yourself up for success on the next “game.” If you’re like most developers, documentation is always an afterthought and it’s something you only do when it’s mandated by a manager. Documentation (in the world of Agile) takes on a completely different meaning – there is no strict format for what constitutes appropriate documentation. It’s simply “whatever is necessary to communicate the essence of the theory or project to those that follow.” That may sound too foofy to some but it’s important because (consistent w/ the Manifesto) it’s not constraining implementation to a particular convention or process but rather focusing on the goal of communicating the important aspects. Cockburn talks about methods like “progress radiators” and videotaped whiteboard sessions as simpler ways of preserving and conveying this understanding. The traditional view of documentation is one of a detailed functional spec that precedes the project and captures every requirement and then some system for documenting the code afterwards to again capture every detail of execution so that it can be understood by programmer’s that follow. According to Cockburn’s advice, a picture is a thousand words and a video is worth a kajillion.
   My Takeaway – I found this to be extremely insightful and especially relevant to what I’m proposing to do with Grid7. Too often developers receive a mandate from management to perform documentation in some nit-picky format that distracts them from valuable time they could spend just making things better. A simple picture of a whiteboard to accompany a paragraph of instructions can go miles towards bridging the knowledge gap and that’s exactly what we used to do at a place I worked called Interactive Sites. I’m all about the idea of videotaped whiteboard sessions though and I have already made it a habit of using my iPod along with my Griffin iTalk to audiotape meetings so that I can refer back to them and bring someone new up to speed by giving them an MP3 of a previous conversation rather than regurgitating it. I plan to hold monthly status meetings via Skype on the Grid7 stuff and you bet we will be videotaping them and archiving them for future developers that enter the project.
6. A “Shared Metaphor” as a common anchor point for developers
   The idea is that when working with complex systems and many developers, if you can develop a “shared metaphor” or a more tangible scenario that parallels the problem domain, people will be able to draw upon these parallels to make decisions and therefore remain more cohesive in their approach than if they lacked the shared metaphor. This contribution was from Kent Beck, one of the originators of the Extreme Programming methodology. I cannot comment on the efficacy of this tactic amongst a dev team having never used it myself, but it certainly sounds like it has merit. I think anything you can do to align the vision of team members to some landmark will have value, especially when the project involves highly abstract concepts.
   My Takeaway – “Having everyone on the same page” is important and there is absolutely value to using metaphors to assist in scenarios when the concepts are abstract. In fact, just last week in my meeting with Value Options and Arizona Behavioral Health regarding the construction of the extranet they will use to collaborate on housing homeless folks, I was able to frame the abstract idea of our anonymous wait list in terms of the red ticket dispenser you see at the post office that dispenses numbered tickets anonymously. We were able to collectively work from that image much easier than talking in abstractions and it helped not only in communicating but we were actually able to discover additional ways of simplifying how the wait list works by drawing on parallels of how the ticket dispenser functions.
7. Tradition vs. Transcendence as the foundation of good design
   In other words, “how much do you balance making the interface for your word processing program look like a typewriter in order to make sense for old school folks vs. making it the cleanest-possible, sensible interface for getting the job done at the risk of alienating people who are less savvy?” This is the age-old question of design (and not just in computer apps). There is some optimal balance that exists in a newly-designed apparatus that meshes tradition with transcending innovation to push the state of the art forward and test the boundaries of what’s possible today.
   My Takeaway -With graphical interfaces especially I know big companies like Microsoft spend millions of dollars in research to find that balance. We had Russ Ruggia, a Developer Evangelist for MS come and talk to our CFUG awhile back and he mentioned that MS had spent something like $7bn in psychology research in developing the forthcoming interface for Windows Longhorn/Vista).
8. Criticality and Team size determine methodology weight
   Any project can be evaluated on a 2D graph that shows team size on the X-axis and system criticality on the Y-axis (system criticality refers to the severity of loss in the event of a bug, lowest being an inconvenience and highest being loss of life). Cockburn breaks down the graph into quadrants and explains why projects that stray further from the origin of this graph require heavier methodologies. Even small projects at NASA demand a heavier-weight methodology than the typical web 2.0 app due to criticality. Likewise, even a large non-critical project with many team members like say, the latest Ubuntu Linux distribution, requires a heaver methodology due to the organization required to manage that many team members.
   My Takeaway – Again, the right tools for the right time. It’s not enough to pick one methodology and stick with it in all situations. The skilled developer will recognize that each tool and methodology has validity in different circumstances and will understand the factors at work and when it makes sense to choose one over the other. I’ve never worked on any of the “L stage” critical projects like medical devices where lives are at stake. I have worked on “Discretionary Monies” and “Essential Monies” projects however while running integration with some of the major credit card processors at Apriva. I can certainly testify to the fact that credit card companies have strict methodologies in place for how things happen, to the point where it can become crushingly burdensome on development. Given the position on the criticality axis of Cockburn’s suggested chart, this decision makes sense however.

Well that was a lot of rambling but I hope this condensed version of Agile Software Development is useful. It was a decent read and not as dense as it may sound. I recommend checking out Cockburn’s talk on ITconversations.com at the link above if you have interest in this stuff. It’s definitely given me some ideas for how to approach things in the forthcoming developer co-op.

sean

© 2005 Lights Out Production – All Rights Reserved Worldwide
© 2005 Lights Out Production – All Rights Reserved Worldwide