ITWorld recently published an article about a study claiming refactoring usually doesn’t result in improved code quality. The authors of the study say “Even though some of those studies claim that refactoring improves the quality of software, most of them did not provide quantitative evidence”
There are other claims in the study that are a little concerning — refactoring doesn’t make code easier to change, doesn’t make code run faster, and refactored code isn’t more resource efficient.
My first instinct is to question the premise and techniques of the study.
But, does the study even matter?
I’ve been working with technology professionally now for twenty-four years, and in all that time, there is one “killer app” that just will not go away. This app may, frankly, be causing stress that is bad for our overall health. I am, of course, talking about E-Mail.
I have E-mail for business, for personal endeavors, and for community activities. My apps send me email to tell me I’m being a slacker about something I should be doing. I have aspired to live the “Inbox Zero” life, and have made several attempts, yet somehow, it always comes back, layers of sediment, to the point where, some days, opening my Inbox fills me with dread.
I’m writing this post from a fresh installation of Windows 8.1 on a MacBook Pro. I spent about half of Saturday researching, and downloading files, installing things, and waiting. There was a lot of waiting.
Systems administration isn’t my idea of a good time, so this was a little tedious for me. There were some lessons learned, and if gathering all of this in one place helps one person, then that’s great.
Here we go.
Well, sort of. To the extent that fail fast enables people to experiment, to try new things, to learn from them instead of continuing to bang their heads against the wall in the hope of getting through — sure. Fail fast is good.
And we can do better.
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?”
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?
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.
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?
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?
I 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 too high — and what are you doing about it?
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.