Do people resist change? The consensus appears to be that they do.
Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.
On the other hand…not everyone sees it that way.
No one can see their reflection in running water.
It is only in still water that we can see. (Lao Tzu)
A friend of mine was telling me about the new apartment he and his family have bought. The building is under construction, and is located in a prestigious part of a major city. We got into a discussion about choosing where to live. He prefers large cities, and I prefer living far from a city (although I work in cities).
Often, companies try to balance staffing with the natural variability in IT workload by engaging contract workers. They don’t want to make a long-term employment commitment to the number of people required to handle their maximum workload. So, they hire enough full-time employees to handle their typical workload, and in periods when the workload is higher they bring in temporary workers on a contract basis. That way, companies can expand and contract staff to match the internal demand for IT services.
Problems occur when the parameters of the temporary staffing engagement are at odds with the nature of the work performed. Because “coaching” has not been a well-understood category of services, it has more-or-less accidentally fallen into the “hourly contract” mode. Is this appropriate? Does this model cause difficulties for any of the three constituencies that have an interest in it: The clients, the workers, and the middlemen?
The bad news for a smart-alecky blogger is that it’s getting harder to find examples of companies that handle their IT function foolishly. But that’s good news for the IT industry!
- calories from fat: (don’t ask)
I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:
“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)
The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.
The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.
Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.
So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.
Yet, they do.
Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.