Emojii.m4a Listen on Posterous

Rough scratch track with some ideas I’d like to expand on later in higher fidelity. Done completely with iPhone 4S and an Acoustic Guitar.

Emojii.m4a Listen on Posterous

Rough scratch track with some ideas I’d like to expand on later in higher fidelity. Done completely with iPhone 4S and an Acoustic Guitar.

I attended Software Crafstmanship North America in Chicago this weekend and came away feeling much differently than I thought I would. I tweeted a summary of my thoughts last night:

@dmosher: I find it interesting that the talks I agreed with most at #scna were predominantly against established “agile” principles …

Twitter is a horrible medium for expressing ideas that are packed with meaning; this post is intended to unpack my tweet and experience at SCNA 2011 by focusing on the 3 talks I found the most valuable and how they formed a cohesive and powerful narrative in my mind.

Suitability vs Capability

Gary Bernhardt gave a wonderful talk entitled “Expansion & Contraction”. I think he should have titled it “Suitability vs Capability” but it was a brilliant talk and the one I considered the best of the conference. Here’s my best attempt at paraphrasing it:

Programming Language and Technology go through a constant ebb and flow of expanding and contracting over time. During expansion, these solutions are “Capability” solutions; that is, they are capable of solving problems but they are not yet suitable. Eventually there is a contraction that happens and “Suitability” solutions emerge.

Java first emerged as a Capability Solution during an expansion in the post C/C++ era. Time passed and a contraction occurred in which Java matured into a Suitability Solution for developing software.

A few times during his talk Gary mentioned that JavaScript and NodeJS are currently in the realm of Capability Solutions. At first this rubbed me the wrong way but I think that’s because I wasn’t really listening to what he was saying objectively. NodeJS is absolutely in the realm of Capability and not Suitability at the moment, but that doesn’t mean you can’t create something useful with it.

Thinking more about the heart of Gary’s talk I find myself glad that it was on Day 1 because I found that it framed my thinking for the rest of the conference.

Programmer Anarchy

Agile best practices are often framed as things we “must do” in order to be successful but I think it would behoove us to frame them in terms of suitability and capability.

Fred George gave a talk in the breakout room on Day 2 entitled “Programmer Anarchy”. His ideas might seem radical to some but I think they are an appropriate response based on an evaluation of suitability/capability for his specific situation. It’s important to understand that the following decisions derive from a company that is continually investing in new ways to make money by building very small applications. Here’s the gist:

Agile prescribes many best practices like Kanban, Scrum, XP, Pairing, Continuous Integration, Unit Testing… the list goes on.

In the waterfall era the power to determine how systems get built lies squarely with the customer. Up-front design docs and requirements specifications dictate how developers should build a system to achieve success. Through waterfall, systems are often built completely wrong. As a result customer trust is lower, developer happiness decreases, and success is not realized.

In the agile era the power to determine how systems get built is shared between the customer and developers but there is a gap in trust because of the past failures of waterfall. Agile is an attempt to bridge the trust gap by building things faster and with less bugs. Through agile, systems are also built wrong but they fail faster which mitigates risk and decreases the cost of change.

In the era of Programmer Anarchy the power to determine how systems are built lie directly with developers.

• non-developer roles like architects, project manager, scrum-master, team lead, delivery lead, hr people and tester are completely eliminated from teams
• developers are empowered to build software using whatever technology they choose and with whatever tools they choose
• applications and systems are extremely small (100-300 lines of code) so unit-tests, acceptance tests, and continuous integration are eliminated entirely
• teams are encouraged to write and re-write applications using whatever they want, including capability solutions (Clojure, NodeJS, Cassandra, Hadoop, etc..)

Fred talked a lot about his company and how they have a lot of trust in their developers to be able to turn ideas into money. The first thing they do on any project is write the business metrics code to be able to verify whether something they produce can be tied back to business value. This is an absolutely critical point that needs to be understood. Most of the time, my dissatisfaction in the work I do is related to not knowing whether something I build will actually have value. If I had metric and monitoring code in place that was able to tell me what I created is making money and can be considered successful my job satisfaction would increase greatly.

Unit tests weren’t suitable for Fred’s teams because they were writing such small applications, so they eliminated them. Traditional “Agile” roles weren’t suitable because he empowered developers to make decisions on what to use, how to use it and which developers would be best suited to building it, so they eliminated them. I think you can see the pattern.

I found it interesting that Fred’s teams got rid of things many in the Agile movement consider to be not only suitable but essential to building good software. It was also fascinating that he actively pushed his teams to use capability solutions like Clojure, NodeJS, Cassandra and Hadoop, which proved wildly successful.

Whether you agree with the decisions or not is irrelevant; Fred’s team made a judgement call about the suitability of all the typical “Agile” best practices and cut away all the things that weren’t suitable. Good teams find ways to eliminate waste by evaluating whether the things they do are capable and suitable and eliminating things that aren’t.

Propaganda, Indoctrination, Fanbois, and Education

I believe there to be a significant difference between a “Big ‘A’ Agile” and “Little ‘a’ agile”. The religion of “Agile” is often touted as the one single way to build software. The number of roles and processes prescribed by “Agile” is excessive, however, this is due to a failure to evaluate things in terms of whether they are suitability solutions or capability solutions for a given project/team.

It was probably surprising to people in the software craftsmanship movement that Zed Shaw was invited to speak, but his talk on “Propaganda, Indoctrination, Fanbois, and Education” was the most thought provoking talk at SCNA 2011. Here’s my translation:

Anyone who tells you that they have found the “one true way” to build software is a con-artist trying to sell you something.

If you aren’t writing code, you aren’t a programmer. Programmers build software, everything else is just marketing spin.

Indoctrination happens when you’re convinced to think something is the only way. Education gives you options and lets you make choices. Don’t be indoctrinated, be educated.

Agile and all the related buzzwordy ideas can be boiled down to these 3 simple ideas:

• Make a list of stuff to do.
• Do that stuff. 
• Automate the heck out of everything.

(note: these things don’t have to be done in any particular order)

While he’s abrasive and rubs a lot of people the wrong way, Zed Shaw has done a lot of good for the software craftsmanship movement. He’s trying to put the focus back on learning programming instead of “Super XP Double Pairing Kanban Scrum Sauce” and all the rest of the “Agile” marketing spin. His “Learn Code the Hard Way” series is wildly successful and is actually teaching people how to program. Somebody at the conference asked him:

“So what do you think about Unit Testing and Continuous Integration and all that stuff then?”

His response was pretty down to earth:

I’ve worked for big consulting companies doing every one of those things in the past. I’ve written tests, done TDD, used pivotal tracker blah-de-bloo or whatever you’re using. Those things aren’t bad but anyone who is trying to tell you those things are the “one true way” to build software is a con-artist trying to sell you something. If you believe that stuff you’ve got a mind-virus. You don’t want a mind-virus.

I used to change my thinking drastically all the time. I’d go to conferences and experience a lot of hype and get infected with a mind-virus that led me to adopt ideas that I would later on discard. This isn’t a healthy thing to do. Nothing I experienced at SCNA 2011 was radical enough to make me change my thinking drastically, but what I did experience will help me to be much more objective about the things I let influence me going forward.

Where do we go from here?

It’s important to be objective. It’s important to question the value of things we do, especially when we do them because somebody has told us they will solve all our problems.

To me, the most important narrative of SCNA 2011, and the thoughts behind my tweet are these:

• Don’t buy into all the propaganda, don’t get indoctrinated. Get educated.
• Learn to objectively evaluate the tools, processes, and ideas we use in terms of suitability and capability. 
• Let go of suitability solutions if they don’t give you any value. 
• Embrace capability solutions because you might be surprised by their value.

I started working as an independent contractor for Pillar Technology over 6 months ago (Nov 1, 2010). At the time, I had no idea what was in store for me; looking back now I think I’ve hit a new point from which to grow in my career so it seems time to engage in a retrospective on the last year.

Some History

Prior to working with Pillar I spent just over 2 years working on a number of projects at VendAsta Technologies. I grew a lot in those 2 years but mostly in a technical capacity. Things like continuous integration, build configuration, and (briefly) unit testing were introduced to me. It was enlightening to get a taste of the technical goodness offered by those things but ultimately I felt like there was no one there who could guide me in the underlying principles that necessitate them. At the same time I was introduced to many of the core concepts of this thing people in the software development community call “Agile”. Coming out of VendAsta in 2010 I thought I knew what Agile was. I thought it was Scrum, XP, TDD, continuous integration and a whole host of other technical terms.

Looking back at where I’ve come in the last 7 months I don’t think I can say I know what Agile is even now, because it is an ephemeral thing that seems to be constantly evolving. What I can say is that I know a lot more about the core of what’s important in software development: delivering business value and earning the trust of those you work with.

Trust and Value over Working Software

My first 6 months with Pillar were served working on a client project for Gordon Food Services out of Grand Rapids, MI. I worked remotely for those 6 months out of an office in my basement that Tanys and I built the week before I started. A brief note on working remotely: it opened my eyes up to a key thing that’s required to be successful in life; self-discipline. I had my doubts about how effective I could be remotely but I decided it was worth the challenge and committed to myself that I would do what it took. Getting up at 7 am to make standup in the morning (hello, 2 hour time zone difference), pushing myself to keep lines of communication open, and pouring my heart and soul into building trust with the client; these are the things I did over those 6 months. And it paid off. I grew in my technical knowledge but also in my ability to cultivate good business relationships.

The people at both the client and Pillar have been great, providing much in the way of the mentoring and leadership around the principles of good software development that I had craved for such a long time. In 6 months working for GFS the team I was part of a team that produced software faster, with less defects, and with more value than any other project I’ve been on. The experience was energizing and opened my eyes to the power of building trust and constantly delivering value all while adhering to solid software craftsmanship principles.

Beyond TDD

Prior to joining Pillar I thought I had a pretty good grasp on the technical concepts surrounding “Agile”. 7 months later my eyes have been opened to how much more than technicality Agile really is. At its heart, Agile is a way of thinking that promotes accountability, integrity, quality, and value oriented thinking. I used to think writing tests was something you did after writing production code to verify the behaviour you had crafted. Now I understand that ”The fundamental conundrum of software development: I can code fast when I have a good design but I can’t design until I’ve coded slowly.” (Kent Beck).

A good design is achieved by thinking out architecture by writing tests first. I’ve also learned that tests can act as documentation by example, so it’s important to continually curate test code so that it doesn’t grow stagnant. Most importantly of all I’ve seen the power of having a codebase with 95%+ test coverage and how that acts as a safety net to making change. This last point can’t be overstated; the freedom experienced through red/green/refactor makes change cheap and development incredibly enjoyable. At the core of my change here from 7 months ago is a paradigm shift in the way I think about developing: I don’t feel responsible writing production code until I have a failing test.

The Best Way To Learn

Something I’ve always felt positive about is my ability to teach. I feel I have the heart of a teacher, which means that I can empathize with people to understand the pain they feel. (I’ve felt the pain too, which always helps). In the last 7 months I’ve been devoting myself to studying more effective ways to promote craftsmanship in front-end development. One of those ways is to teach more. This has not been easy; front-end development has historically been treated as a second class citizen. (I could write a whole other blog post about that alone, but that’s a topic for another time). Breaking down barriers between front-end and back-end developers requires a certain amount of grace and poise that I didn’t have 7 months ago. Being able to effectively communicate solid engineering principles to back-end oriented developers requires empathy, compassion, and the ability to communicate using language they understand.

I’ve often had to put aside my idealism and promote compromise. I’ve also had to become humble and admit that sometimes the front-end is not the place where everything should live. (But I still think there’s a whole lot of logic on the server that shouldn’t be there. Again, another topic for another post). The benefit to engaging developers across architectural boundaries and striving to teach is that I’ve been able to learn a lot. I’ve learned how to effectively test drive JavaScript (/hattip @searls), how to build scalable, object-oriented CSS/HTML, how to achieve an appropriate separation of concerns on the front-end, and how to translate n-tier architecture principles from the server-side to my client-side code. Being at a company like Pillar has provided a rich environment in which to grow; it’s something I’m very grateful for.

The Path to Agility

Many of my co-workers attended the #pathtoagility conference in Ohio this week. I wasn’t able to attend but I think it’s fitting to end a post about my own personal “path to agility” with some forward looking thoughts that can help you (and me) to continue on that path. Software development is evolving and changing; set yourself up for success by being willing to evolve and change right along with it. Agility is more than process or technical solutions; it involves integrity, accountability and a fundamental paradigm shift in your way of thinking. Continue to look for ways you can shift your thinking. Be open-minded. Teaching is a powerful exercise in self examination and growth; try to spend time teaching those around you, it’s worth the investment.

2. Replicate the Environment

Bring the HTML in question into your sample page as it appears in your production code. Also bring only the CSS that applies to those elements and put them in a style block in the head of your sample page.

http://gist.github.com/665183

3. Verify

You probably have some assumptions about what you think the problem is, this is the step where you verify that. Open your sample page in the browsers you want to test in and see what kind of results you get. The goal here is to eliminate the thousands of lines of other CSS and JavaScript that might be altering the way your markup is displayed.

4. Refactor

Once you’ve verified things are behaving the way you want you should probably refactor that HTML and CSS to contain less presentation in your markup. Often markup from legacy applications has been touched by many different people with varying interpretations about how to write HTML; that’s ok but given you spent the time to isolate this problem you may as well do some cleanup.

5. Verify … Again

You’ve made changes, run your test page through the browsers you are testing for again. Repeat step 4 and 5 until you’ve got a good baseline to work with. It’s also good to remember the answer to http://dowebsitesneedtolookexactlythesameineverybrowser.com at this point.

6. Integrate

You were able to eliminate a bunch of redundant CSS selectors and redundant markup. Great! Now it’s time to inject your newly refactored code back into the mess of 50 CSS and 40 javascript files. This can be challenging based on how many dependencies you touched in your refactoring but at least you have a baseline of what to expect now.

Integration is going to result in some more rendering anomalies but now you have a core set of solid CSS/HTML that you know will work. What you do now is go through Firebug/Webkit Inspector and start disabling styles in the cascade that also affect your elements until you get the result you are looking for.

Conclusions

You will probably still have to fiddle but at least you will have eliminated a significant amount of frustration by isolating the problem and proving out your assumptions about how the markup and css will behave in other browsers. Of course you could avoid a significant amount of this cross browser troubleshooting by using something like Compass and SASS, but that’s a topic for another blog post

I hope this was helpful to you and I wish you luck on improving your front end debugging process and reducing the amount of frustration experienced.

I've been playing a lot of basketball at work these days on lunch and coffee breaks. As a programmer who sits most of the day, it's nice to have a place to go to spend some energy. I've been keeping track of my progress in shooting free throws and my percentage has been steadily improving. I think I shot 80% last week (using a general warmup and then 10 in a row as my benchmark). I had what I like to call a "micro-epiphany" the other day when I went out to shoot baskets.  I started thinking about what it takes to be successful at basketball and realized that there are two primary areas of skill required: mechanics and focus.

All I know is that it feels good to play ball again. It feels good to focus