Planning is a polarizing topic in software development. The reality is that all different types and amounts of planning will get the job done, and software made it into production long before people were arguing about when and how a plan was created.
In more traditional waterfall organizations, every bit (or so we thought) of the work is planned out ahead of time, sometimes months ahead of time. Before the programmers go to work, something akin to a small novel will be handed over explaining each little detail of how the software should look and work.
At the opposite end of the spectrum is the agile crowd where the perception is that no planning occurs at all.
Agile software development principles strongly encourage team development, team resource sharing, and the creation and sharing of knowledge. This is a wonderful goal, but why, so very often, do we see the system stacked against the team, and focused on the individual? Think about who generally gets promoted in organizations. This is, of course, subjective. I can’t speak for every organization, but in my own experience, the person who gets promotions, bonuses and higher pay raises tends to be the stand-out individual that “the company cannot live without”. For the sake of this story, let’s call them “the hero”.
We all know these people. They are the ones online at all hours, answering questions, finding some unique way to solve a problem, and being praised for doing so. They ride in to save the day, have near universal admiration of their teammates, and management extols their virtues.
What could possibly be wrong with this picture?
Beware Dependence Upon Heroes
I’ve been thinking a bit about “the heroes” I have worked with over the years. Don’t get me wrong, I think everyone aspires to be heroic at least some of the time. When there’s pressure to make something happen, we look more favorably upon those who say “let’s see how we can do it” than we do on those who say “oh, that’s impossible, it can’t be done”. I am more concerned with organizations that rely on heroes. When a consistent hero is in place, the overall team suffers because the rest of the organization isn’t getting near the attention or the development that the hero gets. The hero inevitably becomes the bottleneck to the progress of the team.
Dependence Breeds Hubris
Hubris is a Greek word for boastful pride of accomplishment and skill. Often, heroes become proud of their place in the hierarchy. They are the “go to”, indispensable member of the team. Their knowledge and skill is essential to the organization. Hubris develops when that person is seen as more important than others on the team. Hoarding information and influence, or cherry picking the plum jobs that will make them look fantastic in others sights is often a result. They may even be the specialists in dealing with the jobs that no one else wants to do. Beware the hero who is reluctant to share the load.
We All Meet Nemesis Sooner or Later
Nemesis is another Greek word. It is the fall that happens after the pride. I have certainly felt its sting over the years. I have played the hero, gotten comfortable in the role, only to find myself at a point where I cannot play that role any longer, and my team then cannot fill the gap left behind. Even worse, some heroes are absolutely opposed to sharing their ideas. They feel that their skills and their heroism is what makes them valuable to the team. I’ve been in this situation as well, and it is the ultimate hubris. Organizations that do not address this find themselves in terrible situations when that person either moves on or finds a problem they are ill equipped to cope with it. Every hero has an “Achilles heel” somewhere.
We Can All Be “Heroes”
I encourage every organization to identify their heroes and give them a new mandate. Share the heroism! This will not magically make everyone else just like them, but by sharing their knowledge and experiences, they will bring up both the skills and the drive of the team as a whole. To the heroes out there, don’t see this as a demotion or a rebuke. See it as an opportunity to make a team of heroes, one that can tackle more interesting and unsolved problems. Team members who stand in awe of the hero, please, stop it! Don’t worship the hero, learn from them. If that’s not an option, develop skills on your own that can help fill areas that are not being addressed. In turn, this may well make you another hero. If that happen, consider it your duty to make a team of heroes your top goal.
On August 1st of 1966, Charles Whitman climbed a tower a the University of Texas and went on a shooting spree. After, the coroner discovered that Whitman had a tumor in the part of the brain that controls anger and aggressive behavior. A few days before the event, Charles wrote in his journal about noticing feeling different over the past weeks and months.
The book leads up to a question of whether we ask the right question in criminal cases: blamability VS ability to be rehabilitated. I think we are asking the wrong questions in software and would like to talk about that.
Probably best known for creating the website that became Yahoo Store (in LISP) and then selling it to Yahoo — along with creating Hacker News and arguably inventing the modern spam filter, Paul Graham spends his time lately running Y-Combinator, the seed venture capital firm he founded in 2008. Y Combinator funded AirBnb, Stripe, Reddit and DropBox, with initial investments of $120,000 now valued at hundreds of millions.
When Paul Graham talks, people listen. Last week he introduced an essay on immigration titled Let the Other 95% of Great Programmers In.
I think he’s completely wrong, and I’d like to tell you why. Continued »
Saying the very word, out loud, can actually create a bad taste in your mouth. Just thinking of the word calls to mind images of a pushy used-car, or timeshare person who won’t take no for an answer. You hate it; I get it.
Today I’d like to describe and invite you to imagine, a totally different world. A world where sales can be helpful, even noble. I’ll describe a few places that are running that way today, right now, and how it changes the entire way services are delivered. Continued »
Last October I talked about how I think of The Internet of Things. Today I want to explore what happens when something goes wrong in technology we depend on.
My first post mentioned a few attributes and a way to define these things that for the most part, have become a part of our everyday lives. Right now, IoT is mostly a consumer novelty section full of watches that will tell you how far you’ve waked in a day and web connected refrigerators. Plenty of people use the devices, but the functionality isn’t exactly mission critical. Lots of other, more complex things are in the works though – medical devices, and cars.
My parents dropped my wife and I at Hobby airport in Houston after spending Christmas week visiting with them. The baggage ticketing line and the security lines were pretty long as you’d expect for the holiday. TSA agents kept our skies safe by patting down the 80 year old lady in a wheel chair in front of us and me before we made it to our gate. She was clearly menacing. My pants were a little loose.
We eventually made it to our gate and after some reading, people watching, and waiting lined up to board when our group was called. But we never made it on that plane.
After waiting about 45 minutes past the board time, the Southwest person at our gate announced that the autopilot system on our plane was broken and we would be taking a different plane from a different gate.
Figuring out a career path is tough work. From a very early age, in the US at least, we are all asked what we want to be when we grow up. At family gatherings, aunts, uncles, and grandparents will prompt you about being an astronaut, or a police, or even the president.
It’s just small talk really, one generation trying to relate to another. But, it does start an important thought process. What do you want to be when you grow up, and how do you get there?
My career has meandered quite a bit so far. I’ve been a grocery checker, life guard, clerk in a photo lab, pulled cable on a construction crew, and now I’m a software tester and a writer.
There is no manual for what your career will or should be. Planning can help though.
Let’s try a thought experiment. Imagine that any reference to any credential, work history or licensing body you or I might have was housed on a central server. Now imagine that server suffered an irreparable meltdown. Boom! In one instance, all the proof of our schooling, our work history, any certificate we ever earned, any certification or credential we may have ever held, is now irretrievably gone. Oh, and we are both looking for work.
What would you do?
Matt Heusser posted a well rounded commentary of “Zero to One” last week, and in it, he asked us to consider and discuss “a counter-intuitive truth” that we know or believe to be true, but flies in the face of convention or current practice. I’ve determined that my counter-intuitive truth fits in with the above thought experiment; those of us who forgo traditional resumes will do better than those who relentlessly polish theirs.
The company I was working for had traditional cubicles and was considering an office redesign. “Extreme Programming” was all the rage; people were talking about war rooms with no walls. I was much more interested in the private office, likely due to PeopleWare, which I read very early in my career. I even suggested to my manager that we ask our design firm to read PeopleWare, too.
The next five minutes blew my mind. Continued »