Every company I have worked with has some sort of technical debt. One organization years ago was so bad, we had to do something similar to debt consolidation. We had gone years without really dealing with various problems in the code and build system. The product I was working on was delicate enough that normal feature development was dangerous. In the end, we made a special team to handle some much needed refactors in our SDK and in our now 4 hour long build.
Like all debt consolidation, this was disruptive and meant we had to do without some team members, and a lot of time was lost to coordinating and merging branches. I’m not convinced the end result was much better than the big ball of mud we started with.
I prefer a more sustainable approach to managing technical debt.
Last time I explained how private equity works. Given that these companies exist to buy and sell companies, and that they have nearly $800 Billion in deals in 2015, it is likely that you, or a friend, will or are working with a company owned by a private conglomerate.
What can you expect, and what should you do about it?
That’s our topic today. Continued »
As family-run founders and CEOs retire, and the children have no interest in running the business, it’s more and more popular that the company sells to a private equity firm. Friends, Colleagues, and even clients call to tell me they are excited that the organization will be run by “professional managers” who “really get it”, “think entrepreneurially” and “want to invest in the business.”
Two years later, they call me back, sick of the management by spreadsheet, outsourcing, downsizing, and the constant demand for quarterly growth.
What’s going on?
A few years ago I ran into a tester at a conference that was moving away from testing work. He was working for a company that had their developers pairing for nearly every code change. What he described seemed like magic. He told me that two developers work on one change until it was done. When he said done, he actually meant done, as in ready to ship. Not some weird internal definition of the word that really means ready to hand this piece of work to some other group so they can do their thing in isolation.
I finally had the opportunity to get some experience in this environment and have some novice observations that I’d like to share.
If you’ve driven down a major freeway lately, you’ve certainly seen the billboards. As we tune them out, the marketing boards became more outlandish, then had 3-dimensional components that got our eyes, then moved to billboards that rotate multiple images. For some reason, seeing the tail-end of ten second show made us want to wait, see the others, hope to glimpse that first one again … and realize it was just an ad for dental impacts.
On the road on in the bathroom, the trick is the same, to catch and hold the attention of a captive audience. Over time, the we tune out the marketing, so the ad executives need to find new ways to ‘juice’ the message.
The exact same thing is happening with technology marketing, and it’s really a lesson in time and attention.
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.