In January I read a news report about the DeepSpec project that is being developed by a few universities through a NSF grant. The press release had some bold claims, specifically that this project might be the answer to many people’s dream of bug free software. I had as emotional reaction to that. Ever since software was a thing, people have been trying to make it bug free. But, no matter how detailed the specification is, or how much *DD the programmers use, or how good the testers are, there are bugs in prod. It’s just the way of the world.
Bug free software may not exist, but that doesn’t mean the DeepSpec research project isn’t interesting or potentially important. Princeton University in New Jersey announced a workshop on the project, so I put some skin in the game and went. Here is a little bit about what I found there.
For years we have been told that tomorrow’s CIO role will not be able to be just a technologist; the role will also require business skills. Of course, most of those articles were written by journalists, executives, and others who were less technical — “people people.”
In other words, tomorrow’s CIO will be more like the authors of the articles.
I always found it odd that the rhetoric continued, even when Larry Page and Sergey Brin turned out to do just fine at Google, or when companies like MySpace and Yahoo were destroyed by “business people.”
Most of the literature focuses on how people need to have business and communications skills to be successful in those roles. Today I would like to suggest something a little different – that system forces tend to pick people with those attributes, regardless of whether or not those things make them successful. In particular, the CTO’s role, which was designed to be technical from the beginning, ends up tugging any CTO to turn into a businessperson.
That might be good. It might be bad. I suspect, at the very least, it is what it is.
Let’s talk about why. Continued »
This morning I awoke to a notice that Justin Rohrman, my fellow writer on this blog, had posted a piece trying to explain where startup founders come from. Justin’s not “wrong”, in as far these things can be right and wrong – but as as a former worker at Socialtext, a once-silicon valley darling funded by DFJ, I thought my experiences might add a little flavor to the piece.
So here goes – Matt thoughts on where founders come from, and what that might mean for me, you, and society. Continued »
The American Dream is dead. But, only in the Princess Bride sense. The American Dream is mostly dead.
I have been spent the last year focusing on what it looks like to start a business and the question of where startup founders come from. The American dream says that anyone can come here with a buck and a dream and become a millionaire. There is also a cute saying that there are no poor people in America, only temporarily embarrassed millionaires. There is a touch of truth to both of those. If someone is ambitious enough, and not put off by risk, they might be able to take an idea and turn it into a business.
I am seeing a pattern in technology startups that is startling, though.
Last time I introduced my negotiation strategy, which shifts the work from in the moment haggling to research. It works well when both sides are honest …
What do you do when the other side is not honest, hiding information at best or actively misleading you?
Let’s talk about it.
Are you ready for the impending robot takeover? I’m not.
Most of the automation I’ve seen slips into our frame of mind through simple business processes. Systems administrators make careers on this. When I first started working in technology, admins were automating as much as possible to make spare time for more important things, like DOOM. The rest of the business world caught wind of that and decided they wanted in. More automation, more productivity, more profits.
I recently wrote about the deskilling effect automation has on trades. Today I’m going to take a slightly different angle. I want to talk about the reality of technology and automation, and how that changes the work. The tasks we perform every day.
What if there were a different way? It would have to allow you to close a deal within seconds, that puts you in charge without any deception or shenanigans. More than that, the person at the other end of the table will appreciate you for it.
Over the years I have found only one method that meets this standard. There may be others, but today I would like to talk to you about my favorite.
Are performance improvement plans (PiP) a gambit to shuffle people out the front door, or are they actually there to help people?
I just finished the new Dan Lyons book, Disrupted, while on a plane flight to Seattle. The book seems equal parts entering a new environment with a terrible attitude, and the bad aspects of every startup I have ever worked for. This isn’t a book review, though. In one part of the book, Dan talks about the ups and downs (mostly downs) of being put on a performance improvement plan. This reminded me of a story about PiPs that happened to an old friend while we were working together in 2008.
How important is standardization to software work, and how much of it do we need?
I spend a lot of time reading about Lean principles, trying to apply them to my own work, and helping to teach the rare class so that others can take these ideas and find ways to work more efficiently. The basics are easy, remove waste from the process so that the only thing coming out of the end of the line is value. The stuff that the customer cares about and is willing to pay for, nothing else.
Like most simple ideas (I’m looking at you, agile) it is easy to misunderstand and go completely off the rails. There are some unfortunate overlapping areas between Lean and Frederick Taylor’s scientific management that might be worth thinking about.
Where does innovation come from, and where has it gone?
My schedule is jam packed lately. I have a nearly full time contract gig that keeps me at my desk testing software most days. After that, there is writing work to be done. That floats up and down depending on the month and what editors need. Add to that a few hunting (metaphorical) excursions each week to talk with new or existing clients about new partnerships and work. Sometimes I forget what day it is.
There is nothing I would rather be doing, but this schedule makes it hard to come up with new ideas. There is a hidden tie between lack of spare time and most modern software processes.