Uncharted Waters


March 2, 2015  9:28 AM

Installing Windows 8.1 On A Mac

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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.

Continued »

February 27, 2015  2:24 PM

Beyond ‘Fail Fast’

Matt Heusser Matt Heusser Profile: Matt Heusser

web-failoftenWhen you consider that “fail fast” is a mantra of the lean startup movement, a silicon valley catchphrase, its own book, and thirty-six thousand google search results, the term must be right … right?

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.

Continued »


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.

board_wiring

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.

GarethBowles

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.

BXP135660

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.

checker-flags-297188_640

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.

Consider

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.

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.

9780385346450_p0_v2_s260x420

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 »


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: