Between operating systems, office tools, and developer tools, Microsoft had a near-monopoly – 97% of computing devices at their peak in 2000. The world moved on from Windows, though, to tablets, MP3 players, phones, watches, and now the internet of things.
It wasn’t for lack of trying. In the 21st century, Microsoft continued the strategy that won them the 20th — work with partners to popularize a great idea. Those older ideas includes an operating system, word processor, and windowed operating systems, while the delivery partners were IBM and every clone-maker ever.
The 21st century hasn’t gone as well as the 20th. The Zune, the various PC Phones, and the Surface never rose to dominance. It wasn’t for lack of trying; Microsoft was too early into the tablet market (twice!) while a least one feature of the Surface, the cover-slash-keyboard, was considered an “innovation” when Apple added it to the iPad three years later.
But the race is over, Microsoft lost. Microsoft’s Surface has a 1% market share; the Windows phone hangs around 2.6%. The few friends I have who have windows devices tend to spend at least four hours a day in Visual Studio – that is, they are Microsoft Programmers. The few who actually talk about those devices, as if that is a normal thing, are all Microsoft MVPs — the award Microsoft gives for long-time supporters.
For the first time in history they face a reality that is not exponential growth, nor compelling reasons to upgrade. There is a computer on every desktop, and WindowsXP seems to be just fine, thank you.
Let’s look at another story of expansion gone to bust.
I do a lot of writing and have gotten to the point where I am passable, not terrible, but not outstanding. I enjoy writing, it gives time to be quiet and deliberate and think about a topic till the moment I’m ready to say something. Public speaking on the other hand, I am a complete novice at that. I have done 3 major conferences and a local meetup here and there.
One of those I completely bombed. It’s ok, I’m glad that is out of the way now. The other two were not bad. At this point, I know how to prepare for a talk and how to put together a slide deck that doesn’t suck. Preparation helps, but a talk isn’t preparation, it is a performance.
My aspirations aren’t in talking at conferences all over the world, but I do want to get more comfortable, and just plain better. Feedback is the next step, the next thing that will help me to do a better talk and performance on the next time around.
It was the best of trips, it was the worst of trips. Well, maybe not the worst, but it certainly could have gone better.
Last week I went to Boston (Framingham to be exact) to speak about domain expertise and hiring at STPCon. And, just last night, I got back home from a quarterly board meeting for a professional organization I sit on the board of.
These trips were drastically different, mostly due to the time I put into planning, preparation, and organization. Planning a business trip seems pretty simple at a high level. Book the flight, book the hotel, done. But there is a lot of minutia and nuance buried in there that can make the trip a pain. I want to share a few lessons and comparisons from these two trips and maybe you can avoid some of the mistakes I made.
Scrum is one of the most popular tools among companies claiming some sort of agileness. Every company I have worked for, or with, in the past decade has had an official daily scrum or at least some sort of daily status meeting that had very clear ties to the scrum format.
Despite the near complete saturation within software companies, most people have problems with the format. The meetings become a benign, no value add, aspect of daily life. Or, they create information overload when the team gets blasted by its own problems on a daily basis.
Is Scrum just a narrow tool that isn’t useful for most teams, or are most teams just plain bad at making use of it?
My colleagues, Matt Heusser and Markus Gärtner have been busy working together to publish a new book called Save Our Scrum.
Let’s see what they have to say.
Companies have a hard time putting out software, and an even harder time doing it on time. There are lots of different things that can go wrong from veering way off course from what the customer wants to never ending problems in implementations to having no clue how far you are from the beginning or how close to the end.
For the past 20 years or so whenever people are having these problems, a new process framework has been the answer. There is XP which puts 2 programmers working on one problem, lean tries to remove all the cruft so that all you are left with is value, and then there is scrum.
Scrum is often one of the first things people try when they want to shake up their development process and hopefully fix a lingering problem or two at the same time.
Why Scrum though? What is the value in this practice?
Many years ago, I had an opportunity to get certified in a number of areas at a company I was working at. This was actively encouraged for a simple reason. The software company that was licensing products for our use and deployment gave us a price break if we had x number of people on our staff certified in particular areas. While the certifications had a specific means to an end, at the end of the day, it wasn’t so much the certification that lead to anything different about the work we did or the responsibilities we were given. A demonstrated commitment to understanding and using the skills we had acquired had more to do with being trusted with taking on greater roles and responsibilities than the certification ever did.
Email has been around for a long time, and is starting to fade from popularity, but it is hard to underestimate how much it changed how professional communication happens. We went from expensive long-distance phone calls that had to be carefully scheduled and timed, to electronic letters that can go around the globe in an instant.
Now, email is the exact opposite of cool. It still gets used pretty often, but instead of pulling up Outlook every time we want to talk to a coworker, it is for things like long form memos from the CEO that end up dissected in a news article a few days later. Stuff that needs to live for a while gets jammed into a wiki where everyone can see it and edit when needed.
Email has traded places with messaging services. It has been a gradual change for sure, different IM clients have been used, especially in tech forward companies, since the mid 90’s. Now, IM is the gold standard for office communication.
Lets take a look at why that is good and bad.
More than once recently, I have both seen and had discussions about DevOps. Usually it begins with someone making the claim that the rising popularity of the term is silly. There are a few different ways to think about DevOps. Something along the lines of — a set of methods and tools that help developers get code into an environment faster — is good enough for me. Practically, DevOps has people writing test automation to reduce testing cycles, using tooling to get builds faster, and building tools to get a product delivered sooner. I like to think the word as an abstraction, like the word agile (or Agile if you must). It covers a vague group of things that you may, or may not do.
The debates I see are usually claims that DevOps is NOT new, ops and development have been working together to release software since the beginning of time. I think they are right to some degree, but I also think it’s worth digging in to.
I’ve had a chance to help out with a number of events this year, many of which have needed to have what are, to me, fairly straightforward technical things that need to happen. Tickets need to be sold (or payments need to be processed), updates need to be sent out, and some fun stuff needs to be planned. Having spent twenty-five years in the tech industry in varying capacities, I will confess that I take many of these interactions for granted. I do some quick research, try out some vendors I’m familiar with, ask some friends their suggestions, and then I implement them. Some of them need a little tweaking here or there, or I discover something I didn’t consider when initially setting it up. A few fixes, and we’re back in business.
When it comes to talking about estimates on this blog, most of our time is spent avoiding them. That is, we talk about #noestimates, or alternatives to estimation. Some times, though, the boss wants a number. Today, we’ll provide one simple reality that companies tend to avoid about estimates … and what to do about it.
Here’s the reality: We never know exactly how long a project will take. Short of a Crystal Ball that tells the future, the best we can come up with a probability distribution; generally a Weibull Curve. To the far left of the curve, we have no chance of finishing the project on time, no chance at all. Then, at some point, we have a blip – the curve tics up. This is the everything goes right date; if there are no interruptions, no multi-tasking, and no re-work, we could get it done there. In their book Waltzing with Bears: Managing Risk on Software Projects, authors Tom DeMarco and Tim Lister call this the nano-percent date, and suggests that technical staff are very good are figuring out that date.
The problem, of course, is that the nano-percent-chance date becomes the date. Powerpoint decks are created with the date as a bullet point; bonuses are slated to go out if the project completes “on time.” All this based on the schedule that has a 1% or less chance of success.
As happens on projects, things do go wrong, and the nano-percent date flies by.
Here’s what to do about it.