“Software,” we learned from
Mark Andreessen
in 2011, “is eating the world.” In the process, software is eating up
organizations and executives who don’t understand it or how to manage
it. As the BB article says, “Now that software lives in our pockets,
runs our cars and homes, and dominates our waking lives, ignorance is no
longer acceptable. The world belongs to people who code. Those who
don’t understand will be left behind.” So BB is offering a tour of the
strange, magical, mysterious world of software for frightened
executives—and everyone else.
This cleverly-written, and often-funny, article begins with
the quandary of an apparently successful executive whose experience and
skills are useless in coping with languages he doesn’t understand,
management practices with strange names he cannot grasp, people he
doesn’t feel comfortable with and threats to his survival as a manager
that are all too real. Software development is consuming an ever-larger
part of his budget while it is becoming ever central to his, and his
organization’s, future.
President Obama participates in an ‘Hour of Code’ event: photo by Andrew Harrer-Pool/Getty Images)
The article follows the executive through an extended lesson
in what software is all about. It describes the different
languages—Java, Python, C, C++, C#, Perl and so on—along with their
strengths, weaknesses and personalities, and even more important the
management practices that are used to direct it.
Managing coders
With a light touch, it gives a simplified and amusing
account of the executive’s encounter with the terminology and management
practices of Scrum, with its daily standups, its Scrum Masters and its
sprints.
“This is real. A Scrum Master in ninja socks has come into your
office and said, ‘We’ve got to budget for apps.’ Should it all go
pear-shaped, his career will be just fine. You keep your work in
perspective by thinking about barrels of cash.”
It gives a fair account of the main management practices of managing software: Agile and Scrum.
“There are as many variations of Agile. I’ve had terrible
meetings in my life when I sat between two teams and one of them
explained, at length, why Agile with Kanban was better than Agile with
Scrum. You could smell the money burning.
“Here is Agile, as I’ve seen it done: You break down your product
into a set of simple-to-understand user stories about who needs what.
You file those stories into an issue-tracking system, often a commercial
product such as JIRA.
“You divide work into sprints of a week, two weeks, or
whatever suits your management style, and you give each sprint a name
and a goal (implement search, user registration), then the programmers
take stories to go off and make them happen.
“Every day your team checks in and tries to unblock one another—if
you are working on the tool that sends e-mail and the e-mail server
isn’t working, you tell everyone. Then someone else steps up to help, or
you stick with that story and do the best you can, but everyone needs
to be working toward the sprint goal, trying to release some software.
And once the sprint is done, you deliver something that actually, really
works and move on to the next thing, slowly bringing a large, complex
system into operation.
“That’s an ideal case. Done well, it avoids magical thinking (“It
will all work when we get everything done and wired together”). It has
its critics and can seem to have as many branches (c.f. Scrum, Kanban,
and “Agile with Discipline”) as Protestantism.
It gives an account of what happens when the troubled executive picks up his courage and attends a daily standup.
“One day you go to the pen where they keep the programmers.
Their standup starts at 10 a.m., and some hold cups of coffee. They
actually stand. Mostly men, a few women. They go around the room, and
each person says what he did yesterday, what he plans to do today, and
if he has any blockers. Most of the people are in the office, so they’re
doing the standup in person; when people are traveling, they do it over
chat. Two people are dialed in, the new hires from Boston and Hungary,
both with strong accents. They tell the same story as the rest.”
The executive gradually becomes comfortable with the world of software.
“They will do their standups. And after the standups, they
will go off and work in the integrated development environments and
write their server-side JavaScript and their client-side JavaScript.
Then they will run some tests and check their code into the source code
repository, and the continuous integration server will perform tests and
checks, and if all goes well, it will deploy the code—perhaps even in
August, in some cloud or another. They insist that they’ll do this every
day, continuous releases.
“Then will come reports. Revenue reports, analytics, lists
of new markets to conquer, all manner of new customer data that will be
yours to parcel out and distribute. That will be your role, as the owner
of the global database of customer intent. Thousands, then millions, of
new facts that can help the company plan its sales and product
development cycles. A good thing. And, you hope, the new site will
generate more revenue, being faster, better, API-driven, and deployed
across platforms to Web, mobile Web, and multiple apps…
“When the site is introduced, you’ll buy the coders a cake
and send them to the JavaScript conference of their choice. You’ve
learned that the only appropriate reward for people who write JavaScript
is more JavaScript. TMitTB will get his bonus. The CTO is already
considering him for new things. You like the CTO. She has become a
friend of sorts.
“You can feel it, the S, off in the distance, coming toward
you. It will arrive in due time, and you will stick it to the front of
the VP in your title and all will be well. The coders all smile at you
in the hall now that you’ve sat in on code reviews and feature
discussions and stood quietly in the middle of standups. You know some
of their names, even if you could do a better job of pronouncing them.
“Perhaps you have a future in software after all.
“Hello World.”
Change or die
Not all encounters between executives and software will end
so happily. Many executives will not make the effort to understand the
new world of software that is emerging or the management practices
related to it. And the new world will gobble them up and spit them out.
Many will find that mastering software involves shedding
some of their basic assumptions about how the world works and how it
should be managed. Top-down directives don’t work in this world: code
responds to intelligence, not authority. Nor does maximizing shareholder
value work in a world in which customers are in charge. So the learning
involves more than mastering the technical aspects of coding. It
involves a different way of understanding and interacting the world. It
is a
Copernican revolution in management.
BB has done executives a great service by providing us with a
simplified Baedeker of this strange new world. Death is not inevitable.
There no longer any need to go on faking your way through meetings
about software. It can be understood. It is the future.
So read the article. Then re-read it. And then re-read it again.
As the editor says, “It may take a few hours to read, but that’s a small price to pay for adding decades to your career.”
And read also:
___________________________-
Follow Steve Denning on Twitter @stevedenning
Comments
Post a Comment