Back in the 1990’s we used to have a long, painful process we called regression testing. That was the final step before pushing the code to production. It happened after the code was ‘complete’, and pretty much involved re-testing everything. Since the code was typically a big ball of mud without well-separated concerns, any change anywhere could break anything, so we had to re-test all of it. The re-testing was to make sure the quality did not regress, with a new feature breaking an older feature. Hence the term “regression testing.”
Most of the automation strategies I get brought in to help with are plans to do just that: Take the regression testing and have the computer do it, click for click. Inevitably this leads to automation delay, and, more often than not, test tooling project failure.
Today I want to describe a more excellent way.
I read an article the other day called Who Killed the Junior Developer. The author talks a little about her experience with job hunting as a new graduate and also what the job advertising landscape looks like. The cliche is that companies create advertisements for a position that they can’t possible fill. They want a new graduate with 5 years of ruby experience, expertise in Angular, Underscore, and some random NoSQL database. And the starting salary is 40K a year in a large North American city. The company decides they can’t find a suitable candidate and then outsources the work to somewhere in Asia or Eastern Europe.
This is hyperbole with a thread of truth. Really though, where are the jobs for junior engineers?
NBC’s smash comedy Parks and Recreation begins with the story of Andy Dwyer falling into a pit.
No seriously he falls into a pit.
He later writes a song about it, called, “The Pit.”
It sounds like about a third of the software projects I’ve worked on.
Tom DeMarco and Tim Lister have a similar term for projects that stink before they are even started, but no one can admit it — The “Dead Fish Project.”
So your team fell in a pit. Or perhaps you have a dead fish on the table.
Now what? Continued »
Around the first of the year I wrote a post about skill development. it covered a handful of things I would be forced into learning over the next year or so. Skill development is something that most people do on the job. There is demand for something new. and someone has to do it. May as well be you. So you fumble through whatever the new skill set for a while and become competent. The first bits of work are probably something you look back on regrettably as soon as you have to make changes there.
This process can be amplified (good or bad) by spending some personal time. It is easy to talk about what people ‘should’ do, but those ideas are usually wrapped up in the idea of a privileged person with unlimited spare time and resources. That ain’t most people, it certainly isn’t me. And yet, there are still some things I want to get good at.
Early in my career, I worked at a company where everyone was assigned multiple projects. Each status meeting was an exercise in explaining why nothing got done but it wasn’t your fault because you were blocked.
The programmer needed access to the version control system, so he was blocked. The IT person needed to set up a new server, so she was blocked waiting for approval from purchasing. Purchasing, if they were even in the room, would explain they were blocked on management approval.
This might have been okay, as the staff had other projects to work on … except those were all blocked as well. A “good” project manager could work as a sort of expediter, haranguing people to get the work unblocked until they give up and do it. Of course, while they did that un-blocking, some other PM would be blocked, which led to the “best” Project Managers being those with the best people skills. Hopefully they were on the most important projects. Sometimes they even were.
While extreme, this problem still exists on many teams in a much smaller way. Team A is waiting for the API from Team B, which needs to get the function signature approved by Architecture, who are waiting for more clear requirements so they can make sure the API is extensible — or in a hundred smaller ways.
Here’s what to do about it.
Imagine for a moment you come into a small team and see a gaping problem with the infrastructure — the test process doesn’t find the right bugs. Instead of running the same tests over and over again, you want to pivot, to address emergent risks. Or perhaps you want to add change the performance tests to run under secure mode to be more accurate. It doesn’t matter what needs to be done as much as your motivation to see it done.
You write a bunch of cards defining this new work, which will take about the next two-week sprint for the whole team. Then you get team buy-in. Next you talk to the product owner about changing the entire flow of the work for two weeks to this new approach.
What’s going to happen now?
The answer, of course, is “It depends.” Most people will recognize it depends on how much schedule pressure the product owner is under, as well as the company culture.
What we often miss is that it depends on the Product Owner’s personal motivation style.
That year was 1999, when Darcy Dinucci defined the term “Web 2.0” to mean sites where the user brings the value. Flickr, Etsy, Youtube and Facebook are all web 2.0 companies. Without customers uploading, adding, and sharing, these sites are just empty shells.
Tim O’Reilly’s List of Web 2.0 concepts (below) includes the wiki, the editable web page. Today there is a wiki plug-in for all the major information sharing tools, but in 2002, there was only one company offering a commercial tool: Socialtext.
I worked at Socialtext for three years, and met some of the brightest minds in the industry. Here’s the story, a little of the why, and how to build something like that in your organization.
Slicing up user stories into something useful has been trouble at every company I have worked with. Usually what happens is the development gets stories in various states. One story is clear cut and takes a day. The description of another story seems clear cut, but ends up taking a week or more. Product management complains that sprints are unpredictable. Each late feature cascades into the next sprint causing something, probably important, so shift off the immediate radar.
Unpredictability isn’t the problem, though. I’m not even convinced it is ‘a’ problem at this point. Unpredictability is a symptom of something going on in the organization. Luckily, it can be fixed and like with most things in life this gets easier with practice.
From what I gather, Google hiring practices tend to be heavy on credential requirements and programming tests. That doesn’t exactly reflect the results of this project. So, how do we cultivate good hiring practices? Or at least, hiring practices that build capable teams?
On board is something technical people don’t seem to think about very often. Bigger companies handle this through the Human Resources department. There is probably a handbook and a series of videos explaining step by step what to do with a new person. IT builds new computers based on employee profiles so that everything is setup on the new person’s first day. The startups I have worked with didn’t have any of this. I had to get my computer setup and figure out what systems I needed access to when someone pointed me to a URL that I couldn’t log into.
I am starting the new year with a new gig, and that reminded me of some of my preferences for the first day on a new job.