- Consulting / Coaching
- Jeff’s Blog
Succeeding With Test-Driven Development at a Distributed Start-up (17-Jan-2018)
In this blog post for Gurock’s blog, I talk about my experiences doing test-driven development (TDD) at a small startup: Where did we succeed, where did we fail, and what would I change?
Four years ago this month, I wrote “The Consulting Legitimacy Cycle,” a post about cycling between predominantly consulting/training and predominantly in-team software development. At the time I’d been consulting for about 15 months, and was pondering when I might next return to full-time development.
It turns out that the answer was “a little more than a year.” I signed on to Outpace Systems as a remote developer in August 2013, and wound down my other engagements to be fully engaged with Outpace by the end of the year. Thus after about 2 and a half years on the consulting side of the cycle, I switched to the development side, where I would spend almost 2 and a half years.
Outpace would turn out to be the biggest challenge I’d had in a long time: a pile of new technologies with which I had little familiarity kept me under water for at least the first six months. I’ll be honest and blunt: I felt like an idiot for a half year.
During those first six months at Outpace, I would bounce virtually every day or every other day to something completely different. It kind of works when pairing… but it sure takes a long time to ramp up on something! We began to replace Ruby with Clojure a couple months in, which was great. But when you code in a new language for a day, and then don’t touch it for a week, it takes a long time to get proficient. At maybe a day a week, it took me six months before I began to feel reasonably comfortable in Clojure.
(Among the bigger learning curve elements: using a Mac daily for the first time, the sheer hell of learning Emacs for someone with a solid preference for vim, and for the longest time, a New Library of the Week. See “Surviving Chaos With Pairing” for the complete list of technologies.)
The upside: I picked up a pile of skills and an updated understanding of the daily feeling of being a real team member, as opposed to experiencing it from the outside as a consultant/coach/trainer. And the regular success we had in delivering software to happy customers lends a lot of credibility to what I learned about process and technique.
I’m convinced that my regular cycling back into “real” development is what helps me relate so well to teams I work with as a coach. They can tell if you really appreciate and understand what their daily life is like.
The downside: the business languishes. I managed to sneak in a few short engagements (mostly training) each year by using vacation. But I was too swamped to invest much energy otherwise: I wrote only a single blog post in two years, my web site started to crumble a bit (and continued to look increasingly outdated), I didn’t tweet much, and most other forms of outreach to customers, existing or potential, languished.
In February of this year, I chose to re-start Langr Software Solutions based on the financial assurance of a regular bi-weekly gig that should last until the end of the year. This time around, I decided that continuing to help deliver real software was going to be in important aspect of sustaining the viability of the business as well. As such, I chose to continue providing services to Outpace, and I’m also seeking to close a freelance development gig.
I’m hoping this continued involvement in “real” software deliver will prevent me from ever having to halt in order to take a full-time development gig again, and will help me keep the business continually vibrant and available. Maybe my Consulting Legitimacy Cycle will change from 2+ years for a half cycle (4+ years for the full cycle) to about a week.
Coming back from a long Thanksgiving weekend is always tough. This year it’s tougher, as I had eight guests stay for four days and thus didn’t keep up to date on things.
I realized I didn’t properly offer up thanks during our chaotic Thanksgiving dinner. So here are some of the things I’m thankful for today.
That’s it. Nothing earth-shattering here.
In doing Sudoku puzzles, most of the time the next solution is staring you in the face. But you can’t see it for all the other numbers in the way.
I got stumped on a puzzle Saturday, one that I’d stared at for about ten minutes without success. I have a ten-minute rule, so it was time for a new tack. (Others might call this ADD, but I follow Weinberg’s Bolden Rule: “If you can’t fix it, feature it.”) I turned the book around to let my son look at it, but continued to look at the upside down numbers. Thirty seconds later, the very obvious solution almost started blinking at me. Duh.
Often, all we need is a different perspective on the problem. Many of us have experienced code enlightenment when having someone read over our shoulder. The usual explanation is that we’re now trying to perceive how others are reading our code. Another thought: Sometimes I suspect that a very brief mental break is all that’s needed.
But maybe it’s just that we’re shifting in our chair and catching the code at an odd angle. 🙂 Next time I’m stumped on code, perhaps I’ll invert my display. Or change my font.
When I’m really stumped I take a hot bath, put on some nice music, and watch the nice rubber duck float by. It’s never failed to evoke an epiphany or two however there’s a downside; this practice tends to raise an eyebrow or two in open workspaces. Also the office rugs tend to get wet.
Looking at things from another point of view (and even being ABLE to see alternate POVs). There used to be a great book out called ‘A Whack on the side of the head’ – basically techniques to unfetter our imaginations and see possibilities where none previous seemed to exist. Hmm.. I need to see if I can find my copy.
In the mean time..ummm, can somebody pass the soap please?
I visited a number of development teams (both C++ and Java) in Krakow, Poland over the prior two weeks. I also had an opportunity to speak at the Agile Poland Users Group. Overall, I enjoyed my visit, but was as always most thankful to return home. The Polish developers were mostly very good and interested in improving upon themselves. I learned a few things from them, and I hope they learned from me.
For many, not all, of the developers, I could offer only “the little things,” as they seemed to have solid basic knowledge. Mostly, I worked with them on improving the readability and maintainability of their tests. I think this refactoring of tests is where the real money proposition can start coming into play–until tests are of high quality, they will continue to be costly to maintain. I hope the developers took “the little things” to heart, because I think attention to them is what distinguishes a journeyman from a master.
It’s been well over a year now since a difficult incident that occurred after I spoke at a well-known software company. I’m normally thankful for people willing to engage in honest debate, and for people who correct me in a constructive manner. That wasn’t the case with respect to this incident: I was basically assailed after the fact by someone who wasn’t professional enough to challenge me in person.
Of course these things are very painful. I still get angry when I think about it. I wonder, “did I really come across as stupid as I was made out to be?” I second-guess myself now, every time, when I speak in front of audiences. I fear that I will be called out, perhaps publicly humiliated again.
With respect to the attack, it was one of those things where where comments were taken out of context. The author is someone who appears to have a personal agenda against not just me, but the entire agile community. Having thought over the whole incident many times, I’ve come to a perhaps smug conclusion: my assailant was acting out of his own fear.
Fear? I doubt he would admit it, and probably doesn’t even know it yet. Fear often masquerades itself as arrogance. Arrogance is knowing that your way of doing things is the right way; it hides the fear that something you don’t completely understand might be better.
I spoke at Agile2007. I got the chance to attend one of Bob Martin’s sessions on Code Craft, about professionalism in software development. If anyone has cajones, it’s Uncle Bob. He projects no fear, and was bold enough to say something like, “software professionals use TDD” in his conference talk. I believe he is absolutely on the money.
Many people claim to fully understand TDD, but insist that it’s something you might do only when “you feel like it.” Unfortunately, that statement right there represents a severe lack of understanding about what TDD is and why you might do it. That’s something I’ve been trying to help correct, by demonstrating first-hand the benefits of TDD and the high costs of viewing it as an optional activity.
I’ll project some confidence, which might similarly be construed as arrogance: soon enough, we won’t talk about TDD. It’ll be like subroutines, compiling, and automated builds–we’ll just do it. The holdouts will become like the dinosaurs who still insist that OO is a passing fad.
Behind this arrogance I have no fear–if there’s something better, show it to me. I haven’t seen it yet, and it’s most certainly not the claims that programmers are smart enough to know when their code is perfect and needs no tests. For now, then, I’ll stick with TDD–all the time.
Yours humility impress me much.
posted by Anonymous gr3ml!n : 10/18/2007 06:33:00 PM
My third relevant computer “experience:” When I enrolled at the University of Maryland in 1982, I had to sign up for a “weed-out” course as my introduction to the computer science department. The course CMSC 110P (the “P” was for Pascal, added that year to replace Fortran) introduced us to some wacky notion called A Calculus of Computer Programming. The esteemed Ben Schneiderman apparently had his hand in the “book” that backed the material, which in reality was a half-ream of paper rubberbanded together.
The course was all about how to create proofs of code, starting with individual operations and moving up to entire functions. It was a very tedious process. If I recall correctly, the course introduced its own proof language, one that bootstrapped itself. (I wish I still had the manuscript since I can’t remember what it looks like). Everyone in the class hated it. It drove me nuts initially, but it did make a big impression on me in terms of how difficult it was to code demonstrably correct functions. I remember spending half the semester on proving a few simple functions.
Wikipedia has some interesting pages about lambda calculus and functional programming languages. I never tried Haskell or ML. The notion of using functional languages to help in programming defect-free code sounds intriguing but also very tedious. Today I still recognize that creating correct code is a significant challenge. While it’s not the same thing, I view TDD as my way of demonstrating similar levels of control over what I produce.
(continued from Origins)
My next relevant computer experiences were in high school. We had an HP/3000 computer, a friendly, stack-based minicomputer. An anonymous donor had supplied our school with the machine and a number of terminals. The students quickly ended up its masters, knowing far more than the operator paid to do the job. I spent a lot of time outside class mucking around with the HP.
The donated HP2640 terminals had screen memory. You could page up to review prior screens, a radical notion at the time. You could even add memory cards, boosting available paging to as many as ten screens! Or, sadly, you could remove memory, which our benefactor apparently did, stripping things down to a maximum of 17 lines. Instead of the standard 25×80, we had 17 lines in which to work.
Seventeen lines isn’t much. Worse, we only had a line editor, TDP/3000 (similar to edlin, but much more functional). That meant the latest command prompt itself was one of those 17 lines, so we really only had 16 lines available to list code. It also meant you had to do quick mental math to come up with a command that listed the appropriate 16 lines, such as L 12/27.
What a nuisance! But looking back, being forced into this constrained environment taught me to construct small functions. That’s something I still find to be one of the most valuable base constructs in programming today (see Small Methods). Functions longer than 16 lines created comprehension headaches, since there was no quick way to scan the entire function at once. Longer routines required at least two list commands, and that’s only if you got the line numbers right.
As an aside, I’m sure programmers killed many more trees than necessary because of the other solution, which was to print out the code. I know people who struggled for years to move away from printouts as their primary mechanism for understanding a program.
I’m not the sort to dwell on my past, at least not most of the time. But recently I’ve thought a bit about where some of my current software development interests come from. I wrote a few of these “origins” down and thought some of them might be interesting enough to share.
My first real exposure to a computer was in the late 1970s, at the Radio Shack located in the local mall. A friend and I would hang around and bang some Basic code into a TRS-80 until we were asked to leave by the staff (usually only when they got a real customer, which was rare, and they were very good about letting us hang out otherwise).
We had bought one of those books containing complete program listings. When entered properly, the three-or-so-page programs allowed us to run cheesy little text-based games. What that meant is that I wasn’t really doing much programming–I was only typing code directly from the book into the trash80, not knowing half of what was going on. I had a small grasp of what programming was all about, but wasn’t daring enough to do much with it on my own (save for a little “guess the number from 1 through 10” application). The code in the books was so daunting–several pages of convoluted code with inscrutable variable names and lots of gotos.
Over time, I remember thinking, “why are things so convoluted?” and figuring there had to be a better way. I would take some of the programs and make small changes to them, such as renaming variables, in order to make them more comprehensible. It’s a practice I continued throughout my career, even when I knew I’d be the only one who would probably ever look at the code. To this day, I still refactor code in this manner as my first approach to better understanding unfamiliar code.
Like exercising, falling off a regular schedule with respect to writing can be tough to rectify. I’ve fallen off of both writing and exercising over the past several months. The high stress of moving to a different state (Texas) had something to do with it, as did the holiday season.
I’m back to exercising, for which plantar fasciitis was also a contributing factor to my temporary neglect. And better, I’m back into a regular groove with respect to writing, having dropped a half dozen articles at Gamelan.com (Java articles) /Developer.com (agile/process articles) over the past couple months.
Thoughts for blog posts and articles are always welcome.