Uncharted Waters

February 26, 2015  6:00 AM

With All Our Programming, Let Us Get Practice

Michael Larsen Michael Larsen Profile: Michael Larsen

In the ITKE Discussion forums, a question was posed that I felt compelled to answer.

“Can someone explain the benefits of my life after completing my Java courses?”

19th century image of machine connected to student's heads.

I am no stranger to course work related to programming. In the mid 1990s, I earned a Certificate for UNIX Programming through the University of California at Santa Cruz. While I completed the Certificate program, much of the advanced C language work I focused on was never used again. The shell scripting I learned, however, I still use today. Why? The shell scripting skills had an immediate and tangible effect on my work.

It’s great to learn a new language, or get some time experimenting with a new framework, but experimenting with it alone isn’t going to help us keep those skills. In fact, the speed in which we lose skills that we develop but don’t use can be frighteningly fast. What can we do to make sure that we actually use what we are learning?

Learn in Public

Whether you have a formal blog or just a dated journal, write out what you learn. Imagine that someone with no experience will be reading later. What would you want to show them? What pitfalls did you run into? Making your learning a public document allows you to capture the learning as it happens, including your frustrations. Those interactions are valuable. They will help you solidify concepts in a way that just writing code will not do.

Make It a Daily Habit

Many friends of mine have had the opportunity to spend two years in a foreign country, and all of them have said the same thing when I asked  how they became fluent in the local language. They didn’t do it by studying grammar rules. They went out into the community with other native speakers. They fumbled around to make themselves understood. They repeated this every day. At some point, it became automatic. They just communicated in that language. Had they not had that daily interaction, it would have never happened. They had to interact, they had to communicate, and it became part of who they were and what they could do. Programming is the same.


Work on Things That Matter

When all we do is the sample problems, copying the answers, we may get a cursory understanding, but we will not develop true proficiency. When it comes time to do something different, we will likely flounder and get frustrated that we don’t know how to make that example we learned work in another context. Everyone goes through this phase, and everyone feels the same level of frustration at this point. Make yourself change contexts. Find different ways to use the examples you are working on, and do so with projects that actually matter to you. Find a problem that is keeping you from accomplishing a task. Use the programming language you are using to help you solve that task, even if the solution is rudimentary. As you learn more, continue to apply it to your original problem. Share your solutions with others. See if they can come up with additional problems you can help solve.

In the end, any skill we learn is only as effective as the work we put into it and the regular practice we do. When it comes to programming, the mantra “use it or lose it” is painfully accurate. You may understand what you are learning, but implementing what you learn, regularly, in real situations that you personally can use, will spell the difference between a passing surface knowledge and an actual skill that you can call on regularly and reliably.

February 23, 2015  10:16 AM

How Netflix Makes Software

Justin Rohrman Justin Rohrman Profile: Justin Rohrman
Software testing

Last week I went to snowy Columbus, OH for a regional software / quality assurance conference called QA Or The Highway. QA Or The Highway is a one day conference, this year, it was preceded by a one day workshop on teaching software test design.


The workshop and conference were fantastic, but the conference keynote was particularly interesting to me. Gareth Bowles did the closing keynote on his experience working at Netflix and why they do a lot of testing in production rather than the normal pre-release testing we see.

Lets take a closer look at his keynote.

Continued »

February 19, 2015  10:14 AM

The World Needs Starters and Finishers

Michael Larsen Michael Larsen Profile: Michael Larsen

I’ve had both the pleasure and the challenge to lead an initiative over the past five years called Weekend Testing. It’s a loose model based on the idea that a session is announced, a mission is declared, and people are invited to participate over Skype. It takes place over  the course of two hours. The sessions are informative, fun and, in my opinion, very organic. While I may have a general idea of a topic or a goal, where the session will go or how it will be received is anyone’s guess.


The biggest challenge for me personally is to try to come up with topics that are unique and interesting. I’m not alone in this initiative, I have a couple of other facilitators that help with developing sessions as well (my fellow Unchartered Waters writer Justin Rohrman being one of them). It was during a recent conversation with Justin, as we were discussing how to propose new sessions, that we started talking about how difficult it can be to make something that is “new”. As we were talking, I shared with him what I call the “Becker-Fagan Effect”. What is that, you ask?

This term comes from the 70s era band Steely Dan and their principal songwriters, Walter Becker and Donald Fagan. Fagan once said about their partnership “Walter (Becker) can’t start a song, and I (Fagan) can’t finish one, so we work well together”. I’ve come to realize over the years that this is a valuable insight to creative work of any type. In my everyday work, the biggest problem for me is getting started. I’m very much a “Becker”. I confess to often being stymied by trying to come up with something off the cuff. Put a blank sheet of paper in front of me and ask me to write, and I will struggle. However, if someone prompts me with a question, or with a kernel of an idea, then I’m off to the races, and I can pull together lots of ideas and initiatives. I contrast this with a variety of “Fagans” that I know. They are wonderful at getting things started, but have difficulty carrying them through to completion.

Our culture tends to credit the originators of ideas. We look to people who wow us with new products and inventions. We honor them with patent protections and copyright to protect their creations. This is understandable, but it hides the fact that, often, others helped them get that idea from a seed to a fully realized idea or product. The final version of an idea is rarely the brain-child of one person. The spark of creativity may come from another place, or the implementation of an idea may be spurred by someone else’s suggestion. In the end, we don’t really know where the start or finish motivation came from, we just know that the product or project crossed the finish line.


I’ve come to appreciate that I often need an initial spark from outside to get my ideas flowing. To that end, Weekend Testing now has an open call out to our participants, where we are asking those who regularly attend what areas they would like to see us address. Examples are:

– It would be great if we could look at free methods of managing projects.
– Could we look at this new utility?
– Are there ways we can simplify performing repetitive tasks?

Each of these is a kernel of an idea, and each of these allows me some latitude to explore, and ultimately come up with a finished session. Sure, I can bring the idea across the finish line, but without that initial idea, I have nothing to finish. Likewise, many people have the kernels of great ideas, but they may not know how to move forward from there. Starters and finishers, we need each other.

February 16, 2015  7:15 PM

More On Social Classes

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Last week, I talked about a way of thinking about thinking of social classes in software companies. The less obvious it is that we make money for a company, or the more often we have to deliver bad news, the less likely it is that we are part of the ‘it’ crowd.

How does the model effect us in a practical sense, and how do we change it from a dart board with defined boundaries, to more of a swimming pool where everyone is mingling?

Continued »

February 10, 2015  5:38 PM

The Work In Progress is Too High

Matt Heusser Matt Heusser Profile: Matt Heusser

Limit WIPI just came back from vacation to 212 priority-one email threads in my inbox. I have two days to hit the high notes on replies, get two proposals in, write an article or two. Then I have two days of technical work, Daddy Daughter Camp, then I drive three hundred miles to help organize a workshop, then speak at QAORTheHighWay, drive Three hundred back, consult for two more. On the weekend I see the family I haven’t really seen since vacation, then dive back in just about the time that program work is due for two conferences and tax season gets serious.

I just emailed Emma Armstrong, a friend of mine at RedGate Software, telling her I had time for a conversation … in about a month.

My work in progress is too high.

When work in progress is too high, you get stressed. The quality of your work goes down. You take shortcuts, and everything takes longer.


One task that takes ten hours can be done in ten hours. With ten tasks, performing one hour at a time, the average task now takes close to a hundred business hours to complete. And those numbers assume that you have no loss in focus as you switch between tasks.

It Gets Worse

Network theory tells us that when a transportation channel gets overloaded, things don’t just slow down to number of tasks*duration — instead, movement slows to a halt. You’ve likely experienced this when there is an accident on a four-lane highway when there is an accident blocking on lane under moderate traffic — you don’t go 75% of normal speed, you drop to 5%. Or less. We call this a congestion collapse event; the less-fancy term is gridlock.


I even had an assignment in graduate school to calculate the speed at which the network would degrade after 75% of capacity was reached – (we used Tanenbaum’s Computer Networking Book)  — the short answer is never run your Ethernet network at over 80% of capacity.

When your work in progress is too high, you end up telling people you’ll call them next month … if you’re responsible. If you won’t, or can’t say things like that, you end up doing everything poorly. The system collapses.

The fix for excess work in progress is finish what you’ve started and not take on new work until you’ve finished. It sounds easy, but a consultancy that does that without ever considering the future will quickly find itself with no work in progress, a very different, and not so good, problem to have.

What Matt Is Going To Do

With some great personal pain I’m going to have to go back to two wonderful conferences and suggest we talk about 2016, not 2015. I’m going to have to tell the folks at TvForTesters and TestingCurator.com “not now.” I am going to let a draft proposal go unsubmitted and tell a friend from another continent, that no, I do not have time to build a talk together, as valuable and fun as it would be, and as much of a slam-dunk, easy-peasy work it sounds like.

Because my work in progress is too high.

I do not want to do these things. I have to do them in order to provide the quality of work my friends have come to know and expect. When I begin to dig out from all this, in early March, things will be a little better, and by April, better still. And yes, I will continue to refine my early-warning systems so they kick in a bit earlier, and yes, I will still need new work – though my ratio of paid to pro-bono may need to go up a bit.

Sadly, too many employees, teams, and divisions, feel they can not do this. Work is pushed onto the team, shuffled around in priority, and people feel they can not say “no” or even “maybe.”

There are a few things you can do, but in the meantime, I’d like to ask the readership: Is your work in progress to high — and what are you doing about it?

February 9, 2015  9:27 AM

Software Development Social Classes

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Companies can be modeled in all different ways. The Gervais Principle, mentioned here a couple times before, slices up companies based on who stays at the bottom and who rises to the top. I have been thinking about a different model lately, one that slices companies into layers based on social classes and social value. Or at least, perceived social value.

Continued »

February 2, 2015  9:25 AM

Scrum: The Art of Doing Twice The Work in Half The Time

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Scrum: The Art of Doing Twice The Work in Half The Time isn’t just a book about scrum. It’s also a book about Jeff Sutherland’s incredible life, a story about how scrum came to be, a touch of Lean and Toyota Production Systems, and some insights about why scrum works.


The first paper on scrum was published in 1995, but Jeff was experimenting and creating the foundation of Scrum before that while working at Easel Corporation. Twenty years have passed now, it’s pretty crazy.

Lets take a look at Jeff Sutherland’s latest feelings on Scrum and productivity.

Continued »

January 29, 2015  6:03 PM

Doing More than “Dropping Bombs”

Michael Larsen Michael Larsen Profile: Michael Larsen

It’s review time in my part of the work world. Once again, it’s time to sit down, examine the year that has past, and objectively determines what it is I have done over the course of the year. Along with this is the question of how this can be reported upwards to managers and HR.

performance review

This can be frustrating. It is a process where I need to look at what it is I am doing in my everyday work, and somehow show that I am doing more than just “doing my job”. The bigger question, however, comes down to “what does it mean to actually do more than my job?”

Continued »

January 26, 2015  2:47 PM

The Peril of Planning

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Planning is a polarizing topic in software development. The reality is that all different types and amounts of planning will get the job done, and software made it into production long before people were arguing about when and how a plan was created.

In more traditional waterfall organizations, every bit (or so we thought) of the work is planned out ahead of time, sometimes months ahead of time. Before the programmers go to work, something akin to a small novel will be handed over explaining each little detail of how the software should look and work.

At the opposite end of the spectrum is the agile crowd where the perception is that no planning occurs at all.

Continued »

January 22, 2015  3:49 PM

Heroes, Hubris and Nemesis

Michael Larsen Michael Larsen Profile: Michael Larsen

Agile software development principles strongly encourage team development, team resource sharing, and the creation and sharing of knowledge. This is a wonderful goal, but why, so very often, do we see the system stacked against the team, and focused on the individual? Think about who generally gets promoted in organizations. This is, of course, subjective. I can’t speak for every organization, but in my own experience, the person who gets promotions, bonuses and higher pay raises tends to be the stand-out individual that “the company cannot live without”. For the sake of this story, let’s call them “the hero”.

Screen Shot 2015-01-22 at 11.39.34 AM

We all know these people. They are the ones online at all hours, answering questions, finding some unique way to solve a problem, and being praised for doing so. They ride in to save the day, have near universal admiration of their teammates, and management extols their virtues.

What could possibly be wrong with this picture?

Beware Dependence Upon Heroes

I’ve been thinking a bit about “the heroes” I have worked with over the years. Don’t get me wrong, I think everyone aspires to be heroic at least some of the time. When there’s pressure to make something happen, we look more favorably upon those who say “let’s see how we can do it” than we do on those who say “oh, that’s impossible, it can’t be done”. I am more concerned with organizations that rely on heroes. When a consistent hero is in place, the overall team suffers because the rest of the organization isn’t getting near the attention or the development that the hero gets. The hero inevitably becomes the bottleneck to the progress of the team.

Dependence Breeds Hubris

Hubris is a Greek word for boastful pride of accomplishment and skill. Often, heroes become proud of their place in the hierarchy. They are the “go to”, indispensable member of the team. Their knowledge and skill is essential to the organization. Hubris develops when that person is seen as more important than others on the team. Hoarding information and influence, or cherry picking the plum jobs that will make them look fantastic in others sights is often a result. They may even be the specialists in dealing with the jobs that no one else wants to do. Beware the hero who is reluctant to share the load.

We All Meet Nemesis Sooner or Later

Nemesis is another Greek word. It is the fall that happens after the pride. I have certainly felt its sting over the years. I have played the hero, gotten comfortable in the role, only to find myself at a point where I cannot play that role any longer, and my team then cannot fill the gap left behind. Even worse, some heroes are absolutely opposed to sharing their ideas. They feel that their skills and their heroism is what makes them valuable to the team. I’ve been in this situation as well, and it is the ultimate hubris. Organizations that do not address this find themselves in terrible situations when that person either moves on or finds a problem they are ill equipped to cope with it. Every hero has an “Achilles heel” somewhere.

Screen Shot 2015-01-22 at 11.47.46 AM

We Can All Be “Heroes”

I encourage every organization to identify their heroes and give them a new mandate. Share the heroism! This will not magically make everyone else just like them, but by sharing their knowledge and experiences, they will bring up both the skills and the drive of the team as a whole. To the heroes out there, don’t see this as a demotion or a rebuke. See it as an opportunity to make a team of heroes, one that can tackle more interesting and unsolved problems. Team members who stand in awe of the hero, please, stop it! Don’t worship the hero, learn from them. If that’s not an option, develop skills on your own that can help fill areas that are not being addressed. In turn, this may well make you another hero. If that happen, consider it your duty to make a team of heroes your top goal.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: