I wouldn’t say that I’m a disagreeable person, I’ve just been in a field that requires analysis and asking questions for so long that asking those hard questions is second nature. I was just plain bad at this early in my career. Years ago, I was in a transitional meeting. We had been developing features for months and were flipping over to a “hardening” phase where we (the development team) were supposed to mainly focus on discovering and fixing problems. We were still wrapping up feature work at that point, and it would have been another week or so before that was done.
I (with out tact) asked why we were calling this hardening since we obviously weren’t there yet. In exchange, I got an hour lecture right on the spot and a meeting with my manager.
In his 1951 Paper “The Imitation Game“, Alan Turing proposed a simple test of artificial intelligence. Put a real person in a room connected to a teletype machine, sending messages back and forth to some other entity. If the entity could be a human, or it could be a computer, and the person cannot tell the difference, then we can say that we have achieved real Artificial Intelligence.
This sort of thing is happening in small ways right now — and is just about to hit mainstream. Continued »
In January, I wrote a little bit about how to do a better job slicing up stories. In my experience, there is always a healthy amount of debate around what size a story should be. Should we make this a 3 or a 5, a 5 or an 8? Inevitably we have to revisit the question of what a point even means. Are we talking about hours of work or difficult or ideal work days (whatever that means)? I don’t think these conversations are terrible useful unless we are intentionally driving to make a piece of work smaller.
So, that begs the question of why do I care whether or not a piece of work is smaller?
I have worked under a few different employee structures in my tech lifetime — all employees on site and in the office all of the time, all employees in the office except for that outsourced team (which quickly grows into several), everyone remote and working from the office or wherever they feel like being that day, and everyone in the office with exception of one or two people. I’m working in that last scenario today. The team is mostly on site, and there are two developers including me that work remote.
Working from home has always been my thing, it’s a comfort zone. I have personal space, and can be hyper productive. Being one of the few people on a team that is remote is an interesting dynamic, though.
Most of the job descriptions I read are either in the form of a job advertisement, or a job description on an internal wiki. Neither are particularly helpful. In the past, I have either avoided applying because the ad listed every skill on earth when what they really needed was a junior. Or, I ran forward and applied to advertisements that were completely understated and well out of my skill range. Bad internal job descriptions can be used like a sword when it comes time for skill assessment and review.
Getting these right always feels like an impossible chore with not a lot of upside. I like to focus on two areas with these, skill and culture.
I got that email a few years ago at an awkward time; I was in Germany at the Agile Testing Days Conference.
So I wrote the email you might expect. For a duration of less than a week, we are talking about consulting, at this rate. At two weeks to six weeks, here’s a second rate. For six to twelve weeks, here’s a third rate. At over twelve weeks …
And so on. There was a lot of “if” and “or.”
Looking around the room, I saw Ilari Henrik Aegerter, known as a sharp negotiator in business. I asked Illari what he thought of my proposal.
His evaluation boiled down to “too many words.” That is, all I needed was one sentence, a single hourly price. If I had an ideal contract length, I could throw that into the email. So the reply could be as easy as “Assuming about six months, we’re looking at $X/hour.”
Done, one line. Yes, we got the deal.
These sort of brief replies will massively improve the chance of success when trying to get to a decision.
Today I’ll tell you why. Continued »
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.