Tech Lead - I do not think it means what you think it means.

    A bit of wisdom from Inigo Montoya for the title of this post. And a bit more wisdom from the Agile Manifesto to ease us into things; "The best architectures, requirements, and designs emerge from self-organizing teams." The line in the title is borrowed from The Princess Bride circa1987, and the Agile Manifesto from 2001, which at the time of this writing, is nearly a decade and a half past.
    A part of much more recent internet history is an article published by InfoQ on my 40th birthday that brilliantly details the concepts of self organizing teams and the broader topic of self-organizing systems. The same article also notes that we basically have no idea yet how to make and support these self-organizing teams. One has to wonder how, given the proliferation of Agile both as a software approach and marketing buzzword, we still haven't figured out this silly self-organizing team thing.

    Welcome to the enterprise software terrordome. Organizations with long standing cultures built on hierarchy at all levels aren't about to just let teams of professionals run rampant. As they've "gone Agile" these companies lost the managerial relationship with developers once held by a proper manager hovering over a row of cubicles. A manager who had paid her dues and was properly institutionalized. What to do? They can't leave real, direct managers in place, because that's not Agile. But they darn sure can't let developers run themselves either. Imagine the chaos that would ensue if a bunch of math, science, and engineering minded individuals were allowed to sort things out themselves. I shudder at the thought of the efficiency and common sense that would linger like a dark cloud over the whole situation.
    Alas, the modern Tech Lead role was born. If there cannot be a manager then there must be some acceptable proxy who can keep an eye on things. To loosely employ Anais Nin, they needed a spy in the house of software. Having served in the Tech Lead role on many teams for many years, what I can honestly offer is that a Tech Lead is the more modern, more technically qualified, incarnation of a manager. Somewhere around the third time I fell for the "50% time coding and 50% time performing other duties" farce, I got the point.
    The existence of these Tech Leads is an organizational crutch. One of many clear signs that we have not yet realized the vision laid out before us in 2001. You see, teams know quite well how to interface with each other and who the experts are on the team. Developers learn quickly who has answers and who they are actually following, generally based on a belief that those surreptitious leaders are technically capable and will provide a fruitful path. It is the broader organization that does not know how to interface with teams, and therefore installs a Tech Lead rather than learning how to work in this way.
    There are some unpleasant side effects that occur as a result. Problems that should be owned by all team members become Tech Lead problems. Decisions that should be whole team decisions become Tech Lead decisions. Evaluation of team members inevitably get proxied through the Tech Lead instead of being managed by the team themselves. The wisdom of crowds is lost. The virtuously lazy nature of humanity kicks in and the whole notion of a team working as equals toward a goal goes right out the window. I could go on...
    I say a good Tech Lead, a really truly good Tech Lead, who is focused advancing our profession and doing what is right, is trying to figure out how to eliminate the need for their role. It would be easy to say this is the responsibility of the companies we serve, but it won't get us the outcome we desire. It's on us, Tech Leads, to teach the people around us how not to need us. Then we'll have really done something.

Not(!) My Hero, Sprint Zero**

tl;dr

If you are about to have a Sprint Zero that intentionally does not deliver anything of value to the Product Owner, you are making a mistake.  Please reconsider.

the rest of the story

Like everything else we humans get our hands on, the concept of Sprint Zero is being abused lately and used as an outright retreat into practices we know don't lead to business value.  I am going to come right out and assert that at the heart of the matter is fear...at the team, leadership, and maybe even organizational level.  How we behave when pressed to deliver is a great litmus test for the character of our development culture.  Sometimes, as with these sprints designed specifically not to deliver anything of value, we don't pass that test.

Every one of us worth our salt knows the code we write will tell us if our project structure is any good.  The humans writing the code will tell us what they still need to learn.  The tests will tell us if our product is shippable.  We also know that no matter how much we plan, many of our assumptions and approaches will change as we learn.  The shortest duration to turning over all the rocks along our path and seeing all the truths about the software we are attempting to conjure is to try to write it and observe what happens.

So why then do we not just start every project by trying to deliver some part of the value?  In most cases, whether justified or not, because we are afraid to be wrong and especially with an audience.  We want to design a little more, learn a little more, delay a little more...and hopefully stack the deck in our favor so that there is something impressive for the demo at the end of Sprint...ONE.  This is a very human thing to do, but still wrong.  It signals to me that we have not yet overcome this silly fear around performance, or worse, that something about the environment makes it an unsafe place to be wrong and sometimes both I suspect.

We are humans.  It is OK to be imperfect in this creative process.  As a matter of fact, it is one of the ways we learn most effectively.  Dive headlong into the ambiguity and start trying to put the 1's and 0's where you think they belong.  You will know in short order whether or not you got it right and you will learn loads of useful things for the effort.  If you feel like you need more architecture, oversight, and process to keep your teams out of trouble...you have much bigger problems.  And they will not be solved with any amount of code...or architecture, oversight, and process.

Less chatter...more code!

**For the record the original title of this post was "!My Hero, Sprint Zero" but I was not sure the less technical types would pick up on the "!" as meaning "not"  :-)

My e2e Top 3

Having an automated end to end test suite can be a super comforting assurance that your application is in a ready state.  Nothing says 'ship it' like having just run a user-like test against every independent feature in the application with no mocks.  Maintaining that test suite can become like battling a hydra if the tests are not properly built though.  I was on a team a few years back that spent about 40-60% of the day maintaining existing cucumber tests.  That is counterproductive and just plain painful.  People get cranky about that sort of thing.

Before I dive in let's lay out a working definition of End to End tests for this post.  I define End to End (e2e) tests to be those that interact with the live application through the user interface and very rarely, if ever, mock functionality regardless of who maintains that functionality.  Tools such as Cucumber, Protractor, Geb, and RSpec are commonly in used to write these tests.  Techniques such as ATDD or BDD generally yield e2e tests.  E2E tests are at the top of the testing pyramid and there are far fewer of them than unit tests.

OK, academia complete...on to the good stuff...

Thing One - specify behavior, not implementation

You would think that a practice rooted in the name Behavior Driven Development would make this point obvious, but we continue to get this wrong.  Any time you find yourself using words like "Page", "Button", "Link", "Text Box", "Drop Down", "Radio Button", etc. in an e2e test specification it is a smell and you should consider whether or not there is a better way.  The reason may not be obvious at first, but what occurs with these tests is that they become increasingly brittle over time.  As the application matures and the implementation morphs these tests become a maintenance headache.  Although there is more to it than just names, they honestly best illustrate the difference.

Tests that should serve you well over time

• The XYZ Application should allow the user to enter and store address information.
• The User Information feature should allow the user to navigate to the Item Ordering feature.
• The user should be able to view all previously ordered items in History.

Tests that will eventually make you wish you never wrote them

• The XYZ Application should have an address form with Street Address, City, State, Postal Code fields.
• The user should be taken to the Order Page upon clicking the Place Order Button on the User Information page.
• The user should see a table including Order Date, Item Name, and Order Cost on the History Screen.

Thing Two - use abstractions to isolate implementation awareness

In most cases these days this really boils down to using the page object pattern.  Regardless, the important point is that there should be exactly one place in the entirety of your e2e test suite where location of a given UI element takes place.  There should be an object (used very loosely here) whose single responsibility is knowing how to get a hold of the UI and interact with the elements.  Any e2e specification should use these objects to locate and retrieve UI elements and and never do so directly in the spec.

For example, there is a fantastic explanation of how to accomplish this in AngularJS/Protractor over on the ThoughtWorks blog.  I implemented this pattern over the last few months with a web development team at a client site and we have all been very pleased with the outcome.

Thing Three - don't test against specific data, but if you must, control it

I cracked open a failing e2e spec the other day that was expecting 4 rows of data in an HTML table  and only found 3.  I didn't see anything in the 'arrange' portion of the spec that was loading the data so I scrolled up to the 'beforeEach'.  Nothing there either.  Hmmm...OK...Pardon me while I flip a table!

In all seriousness, if for some reason you are compelled to look for specific data in an e2e spec, be sure the spec is managing the test data.  A test that is written to be dependent on data from a completely separate process is going to fail and probably sooner than you think.  Better still is to try and keep most of the e2e specs data independent.  If the behavioral assertion can be vague enough to simply check that there is data, for instance, then let it be less precise for the sake of always being accurate.  There should be a unit test somewhere that handles making sure inputs equal outputs and the name doesn't end up in the address attribute of an object.

A data independent approach can occasionally leave holes in assurance.  For instance, if the wrong data field is bound to the view and the e2e test doesn't inspect the value of the data in the view the mistake can go unnoticed.  In these specific cases decide what is least painful for your team, but try to keep control of things so that the test doesn't fail next week.  Maybe a mock is in order, or an inserted row in the back end database, or perhaps a regex to ensure the data at least meets certain criteria.

Thanks for reading this far.  Happy testing!

Why Are We Here?

So, I'm getting old...or at least older.  I made it to 40 this year and lately find myself asking all sorts of decidedly silly questions that 25 year old Don did not care about in the least.  Recently it was how does a software developer really express value? Deep, right...  I am sure a question of this sort immediately preceded the invention of Scotch, in fact.

The obvious answer is producing code.  The path from code to business value is an easy one to map out.  I do see people wondering off that path regularly, but we know it's there and can usually find our way back.  That's likely a topic for other posts.

A quick second in my responses...to myself...was 'making more developers' which I further refined to 'making other human beings better software developers'.  IMHO, this is how we advance as a profession.  And that, I think, is at the core of the matter.  I would like to know that in the grand scheme my actions in this decade have contributed to a positive outcome for the generations of developers that follow.

On a soon to be related note, a few years ago I went to work for a great company as a consultant.  The owner of my company has since beaten into my head the idea that if we do not raise our game beyond solid engineering we will never be able meet the growing demand for software.  To his way of thinking, unleashing the creative and innovative mind of the human beings that write code is the only way forward.  And I tend to agree.

At the intersection of these two ideas; developing human beings into happier, more productive software craftsman and providing an environment for creativity, is an interesting place.  It leads to several changes in behavior.  All of the sudden you have to get to know people on a different level before you hire them.  You have to provide a physical environment that evokes more than efficiency.  There's a whole lot more touchy, feely humanity involved.  And that scares people because many of the usual categories and containers and even tactics we use with humans in business don't apply any more.

A few days ago I warned my management team to be ready for things on the client site to get weird.  We are making some fairly massive changes there and I didn't want them to be surprised when the calls came from people who were confused.  The same advice applies to all of us who find and serve software developers.

As coaches and leaders, be ready for things to get weird.  Actually, make sure they get a little weird.  Know that people can code, but also get know what makes them tick.  Maybe you really do need better furniture, or team movie over lunch, or legos at your pairing station.  Maybe an outlet like 'lightning talks' once a week covering important things like the superiority of music recorded on vinyl is precisely the thing that will send developers back to their IDEs ready to create code like a boss.

My hope is that if we start looking at the people we work with as a creative force and add that to their career offering we can advance the profession.  If it is expected that we grow in our creative outlets as well as our technical tool chest we should unleash some pretty non-standard solutions to the really hard problems coming at us as business becomes more and more dependent on software.  Put more simply I guess I wouldn't expect 'out of the box' answers from people I never let out of the box.

What's in a Name?

    Standing before me yesterday was a very well educated, well spoken, well dressed, and well intentioned pair of gentlemen who are administrators at a local university.  I really enjoyed meeting these guys and hope I get a chance to work with them.  They had questions, lots of them and good ones about how to change the development culture at their shop.  As our conversation progressed in the lobby of our development studio it was all smiles and nods and handshakes.  That is until someone used the word "resource" in reference to the group of human beings that author software for the aforementioned university.
    While I did not respond verbally, I am sure my face gave away my dislike of the term.  And after we wrapped up our chat, I found myself being critical of my own opinion.  I wondered if I was just being a silly, high-maintenance jackass about the phrase.  I have been on an anti-'resource' mission for 7-8 years now.  Maybe it's time to chill out a bit on the topic.  But then again maybe it's not :-)
     I don't want to get into an entitled, 'special snowflake' situation.  I do want to humanize the art and craft of software development.  The idea that developers are some fungible asset that can be leveraged on any project with equal outcomes is silly.  I sincerely doubt that silly idea was the impetus for the comment mentioned above, but speaking in that way leaves the door open for interpretation.  So...I disapprove. (shocker, I know)
    Software development is in a protracted period of transition.  Business and IT are quickly becoming the same thing, or at least combining to become the new state of things.  Software developers are the authors of the context in which business will be done for the foreseeable future.  In order to allow these human beings to do their best work, we need to be deliberate about creating an environment where uniqueness and creativity are the norm.  We want the best from our software developers so that we can continue to advance the business of IT and/or the IT of business.  The leaders among us need to expend effort making that happen.  Choosing our vernacular, our physical spaces, our processes, and our tools are all part of that equation.
    So pretty please, don't call us resources.

The Better Half

    Paired programming is great...except of course for when it's not.  On those tough days it is a developer's own annoying trip through hell and back with a deadline.  I've had it both ways.  I have had my most and least favorite days in software while paired up with another developer.  I wish I could end this paragraph now with some sagely formula for always having a positive pairing experience, but we are dealing with people and it's not that easy.
    As a consolation prize I do have a recent experience to share which you may find useful, or at least familiar.  As it turns out I spent about 11 months in 2013 on a team in the middle of a really interesting C++ project.  Prior to joining that team I had not worked in C++ for well over a decade.  As a result I went from SME to FNG overnight.  This also meant that I had to learn how to be effective as the inexperienced half of a development pair, which I don't do nearly enough. (Note to self)
    Trying to learn the domain, learn the language, and not impede delivery is tough.  Being confused can be a little demoralizing at times.  And constantly asking questions makes me feel way more vulnerable and annoying than I would prefer.
    That's the job though, so my advice to myself was to suck it up, get coding, and try not to ask the same question more than once.  That realization, as simple as it reads, seems to get lost most of the time.  From what I can ascertain most new team members get paired up and actually have little or no idea what their responsibility is as the new pair partner.  I suspect most just assume they are along for the ride and someone will tell them what they are supposed to do.
    Of course, I have a differing opinion on this matter.  Your job as a new team member and pair partner is to become a contributing member as quickly as possible, which can be as little as a few hours.  Everything you do during your first days and weeks on a team should map back to that goal.  This means questions, lots of them.  It also means reading every applicable thing you can get your hands on, trying to pair with and get to know as many team members as you can, understanding team norms and cadences, and keeping your teammates aware of where you are strong and where you need help.
    On the most successful teams I have seen new team members are pushing code in their first few days.  When these same women and men are asked weeks later about their experience of joining a high performing development team they always say the same things - "On most new jobs you sit around and wait for a machine to be delivered and read documentation." , "Getting to contribute working code in my first week on the team was great."
    So...the formula's easy right.  The most obvious business value of a new developer on a team is in his or her code...so be coding.  Coding will tell you what you don't know and what else you need to be doing.

Less Chatter...More Code

    Lately I have been struggling to find time to code.  As a lead on a team the size of ours my day is usually peppered with meetings, CI server shenanigans, process questions about blocked story cards and occasionally a really fun bug.  Every one of those things is enjoyable in it's own right and help the team move forward but I definitely enjoy the times when I can get my fingers on the keyboard.
    When I am given the opportunity to dedicate some time to coding outside of the job I like to make the most of it.  Whether it's the local user group meetings or the weekly lunch time code club, I genuinely look forward to sitting down for a bit and doing nothing else.  There is no substitute, as they say.  And these days it doesn't really even matter all that much to me what language I am writing.
    At many of these events, however, I have found myself disheartened by the number of people who are unwilling to take the keyboard.  Actually, that's not the whole truth.  I find myself disheartened by the number of people who will tell you at length how they would approach the problem, but don't seem to be doing much, if any, coding.
    I started to write a bit here on why I think this occurs, but in all honesty, I don't really care all that much and I am probably wrong anyway.  What I will say is that about six months ago I was at a Global Day of Code Retreat event here in Columbus, Ohio.  During that day one of the constraints put on me was to pair with another developer silently for roughly an hour.  And during that time my pair partner and I turned out some really decent, very expressive code.
    Afterward we both agreed that the silence limitation turned out to be quite eye opening.  We confused the hell out of each other a few times and rewrote each other's stuff more than a few times but once the debate in code was over and the dust settled, we had gotten further on the solution than with any of my other pair partners all day.  Even if we hadn't though I would still say being forced to express my ideas solely in code was refreshing.  As it turns out developers can have a perfectly fine discourse right in the editor and arrive at a very good end result.  Furthermore, we don't have to live with a busted idea for more than the time it takes to revert or refactor.
    So I say fight the habit to socialize every idea before you lay it down in code.  Resist the human urge to gain acceptance ahead of time and get your ideas written and compiled as fast as you can.  Code it.  If it stinks, recode it, or throw it away.  That's what git reset --hard is for right!?  Go forth and be awesome...or be wrong.  Who cares which?  Just be coding.