Tag - process

Sarah Sharp is a member of a very rare group. She's a Linux
kernel hacker. Even among that group, she's unique - not because of her gender
(though that probably is distinctive in many of the group's social gatherings),
but because she's brave enough to demand civil
behavior from the leaders of the community. I applaud her for
that.

Now, I have immense respect for Linus Torvalds and his crew. I've
been a direct beneficiary of Linux in both professional and personal contexts
for soon to be two decades. The skills this group demonstrate are possibly only
matched by the level of quality they demand from each other. However,
unfortunately that bar is often demonstrated only on the technical level, while
the tone of discussion, both in-person and on the mailing lists, can turn quite
hostile at times. It's been
documented many times, and I can bring no value to rehashing that.

However, I wanted share some experience from my own career as a
developer, manager of developers, and someone who has been both described as
demanding and who has needed to report to others under very demanding
circumstances. I've made some of these mistakes myself, and hope to have
learned from them.

Perhaps not so surprisingly, the same people in the community who
defend hostile behavior also, almost by rule, misunderstand what it means to
behave professionally. There's a huge difference between behaving as in a
workplace where people are getting paid, and behaving professionally. The
latter is about promoting behaviors which lead to results. If being a asshole
was effective, I'd have no problem with it. But it's not.

To consistently deliver results, we need to be very demanding to
ourselves and to others. Being an uncompromising bastard with regards to the
results will always beat accepting inferior results, when we measure technical
progress on the long run -- though sometimes experience tells us a compromise
truly is "good enough".

However, that should never be confused with being a bastard in
general. Much can (and should) be said about how being nice to others means
we're all that much happier, but I have something else to offer. Quite simply:
people don't like to be called idiots and having personal insults hurled at
them. They don't respond well to those circumstances. Would you like it
yourself? No? Don't expect anyone else to, either. It's not productive. It will
not ensure delivering better results in the future.

Timely, frequent and demanding feedback is extremely valuable to
results, to the development of an organization, and to the personal development
of the individuals. But there are different types of communication, and not all
of it is feedback. Demanding better results isn't feedback, it's setting and
communicating objectives. Commenting on people's personalities, appearance, or
otherwise, let alone demanding them to change themselves as a person isn't
feedback nor reasonable. Feedback is about observing behavior and demanding changes in the behavior,
because behavior leads to results. Every manager has to do it, never mind
whether they're managing a salaried or voluntary team.

However, calling people names is bullying. Under all
circumstances. While it can appear to produce results (such as, making someone
withdraw from an interaction, thus "no longer exhibiting an undesirable
behavior"), those results are temporary and come with costs that far outweigh
the benefits. It drives away people who could have been valuable contributors.
What's not productive isn't professional. Again - I'm not discussing here how
to be a nicer person, but how to improve results. If hostility helped, I'd
advocate for it, despite it not being nice.

The same argument can be said about using hostile language even
when it's not directed at people, but to results. Some people are more
sensitive than others, and if by not offending someone's sensibilities you get
better overall results, it's worth changing that behavior. However, unlike "do
not insult people", use of swearwords toward something else than people is a
cultural issue. Some groups are fine with it, or indeed enjoy an occasional
chance to hurl insults at inanimate objects or pieces of code. I'm fine with
that. But nobody likes to be called ugly or stupid.

In the context of Linux kernel, does this matter? After all, it
seems to have worked fine for 20 years, and has produced something the world
relies on. Well, I ask you this: is it better to have people selected (or have
the select themselves to) for Linux development by their technical skills and
capability to work in organized fashion, or by those things PLUS an incredibly
thick skin and capacity to take insults hurled at them without being
intimidated? The team currently developing the system is of the latter kind.
Would they be able to produce something even better, if that last requirement
wasn't needed? Does that help the group become better? I would say hostility IS
hurting the group.

Plus, it's setting a very visible, very bad precedent for all
other open source teams, too. I've seen other projects wither and die because
they've copied the "hostility is ok, it works for Linux" mentality, but losing
out on the skills part of the equation. They didn't have to end that way, and
it's a loss.

Among the people I interact with, and in the places I frequent, a question
that comes up a lot is "what exactly is a minimum viable product?". Perhaps
that tells you something about me, but let me tell you something more, and
offer one answer to the question.

Back at the end of the 90s, between preparing for having a great bash for
the Millenium and various other activities of the sort, I was also learning how
to apply the software skills I had acquired to some sort of purpose which would
pay my bills. I ended up, to a large degree by accident, to spend about four
years of the rise and height of the dot-com boom at what I to this day consider
the best possible school for creating great Internet apps for end users: the
Helsinki offices of Razorfish, then-legendary marketing, technology and
management consulting agency, now simply a legend.

In those days, we would at times come across a situation in which a pitch
for a project, a client relationship, or a business idea consisted mostly of
what we called the "Photoshop application" - a web site consisting of
screenshots of something that had not been built. Coming from a developer point
of view, and being rather proud of the skills we had collected, like any
20-something developer is, we saw these as something to laugh at. It's just a
bunch of screens, it doesn't do anything! Anyone could come up with that!

Now, in some cases that's probably true, anyone could have come up with
that. They weren't all great. Some were, and I would grow to respect the skills
and effort people who took design seriously would apply to coming up with both
great interaction, and beautiful looks for software. These are things not to be
underestimated, because impressions matter a great deal, and nothing kills a
budding consumer relationship faster than a dead-end transaction flow. There's
something more than that to designing applications on the screen level, though,
and listening to a recording of
Bill Gross (of Idealab) talking at Stanford reminded me of one part of
it.

At the end of that talk, he recalls the story of Carsdirect, of giving the
founder a small budget and 90 days to prove there's a business. In other words,
to find out whether anyone would buy a car from this site, without talking to
the dealer. Turns out that once they got the web site up, in the first day four
people did just that - buy a car. They would have to go and buy them from local
dealers themselves and deliver the cars to their first four customers. However,
what was NOT important to proving the business opportunity was whether they
would be able to form a dealer relationship with auto makers, figure out the
logistics of car delivery up front, and so forth. For the four first customers,
it was enough to drive the cars from the dealer's lot up to their driveway one
at a time, by the founder!

This is the MVP - the minimum viable proof of business. The front-end of a
business is where value is delivered. Sometimes you can prove that with just by
showing Photoshop images of the service to prospective customers. Sometimes you
need to have a prototype site up that looks and feels like a real business.
What you will not need is to figure out the supporting processes, back-end
business logic, and a whole partner value network to prove business potential.
Sure, those are things that you will need to figure out to turn a profit - but
without the front-end facing the customers and acquiring sales, there's no
revenue, there's no business, and there's no chance of profit, never mind how
wonderful your back-end would be.

Looking back, I'm not sure I knew this back in the days. I was lucky to have
people around me who did. Today, I still see a lot of people thinking of future
businesses worry about the back-end processes before they've figured out
whether there is a front-end business. Tackle the front-end first. Sometimes
Eric Ries's "spend $100 on Google AdWords and see if you get any clicks" is
enough to do that, sometimes you do need a web site resembling a real service.
Do not waste your precious runway building out something to support even the
first 10 customers through the entire product delivery before you have one
customer, though! If you get even one customer, you're learning a ton about how
your next product version is not what you though it would be.

Having recently witnessed the powerful effect establishing a robust
vocabulary has on the process of design, and seeing today the announcement of the oft-delayed
Nokia N9 finally hit TechMeme front page, I again thought about the common
misconceptions of creating software products. It's been a while since I posted
anything here, and this is as good a time as any to do a basics refresher.

A typical axis of argument sets software engineering somewhere between
manufacturing and design. I, among many others, have for years argued that the
relationship of software to physical manufacturing almost non-existent. This is
because while the development process for a new physical product, like any
involving new creation, starts with a design phase, the creation of a
specification (typically in the hundreds of pages) is where the manufacturing
really only begins. The job of the spec is to outline how to make the
fully-designed product in volume. In comparison, by the time a software product
is fully-designed and ready to start volume production, there is no work left -
computers can copy the final bits forever without a spec. There's more to that
argument, but that's the short version. Creating software is the design part of
a product development process.

So, goes the line of thinking, if software is design, then it must be right
to always begin a software project from zero. After all, all designs start from
a blank sheet of paper, right? At least, all visual designs do... No good comes
from drawing on top of something else.

If this truly was the case, what do you think they teach in art schools,
architecture departments, and so on? Technique? For sure, but if that was all
there was, we'd still be in the artesan phase of creation. History? Yes, but
not only that. An important part of the history and theory of design is
establishing lineage, schools of thought, and vocabularies which can serve as a
reference for things to come. All truly new, truly great things build on prior
art, and not just on the surface, but by having been deeply affected by the
learning collected while creating all which came before them.

Not having actually studied art, I have only a vague idea of how complex
these vocabularies are, and this is an area where a Google search isn't going
to be helpful, as it only brings up the glossaries of a few dozen to at most a
hundred basic terms of any design profession. This is not even the beginning
for a real vocabulary, since those describe to a great detail the relationships
of the concepts, ways of using them together, examples of prior use, and so on.
However, even from this rather precarious position, I will hazard a statement
which might offend some:

Software design, in terms of the vocabulary required for state of the art,
is more complex than any other field of design by an order of magnitude or
more. The practical implication of this is that no new software of value can be
created from a "blank sheet of paper".

This will require some explanation. Let's tackle that magnitude thing
first.

Any complete software system, such as that running within the smart phone in
your pocket, measures in the tens, if not hundreds of millions of lines of
code. LOC is not a great measurement of software complexity, but there you have
it. In terms of other, more vocabulary related measurements, the same system
will consist of hundreds of thousands of classes, function points, API calls,
or other externally-referable items. Their relationships and dependencies
to each other typically grow super-linearly, or faster than the total number of
items.

By comparison, the most complex designs in any other field are dwarfed. Yes,
a modern fighter jet may have design specs of hundreds of thousands of pages,
and individual parts where the specs for the part only are as complex as any
you've seen. Yes, a cruise ship, when accounting for all the mechanical,
logistic and customer facing functions together may be of similar complexity.
And yes, a skyscraper design blueprints are of immense complexity, where no one
person really can understand all of it. However, a huge part of these specs,
too, is software! Counting software out of those designs, a completely
different picture emerges.

None of these designs would be possible without reusing prior work,
components, designs, mechanisms and customs created for their predecessors.
Such is the case for software, too. The components of software design are the
immense collections of libraries and subsystems already tested in the field by
other software products. Why, then, do we so often approach software product
development as if we could start from scratch?

Why was it that the N9 reminded me of this? Well, if stories and personal
experiences are to be trusted, it seems that during the process of creating it,
Nokia appears to have "started over" at least two or three times. And that just
during the creation of one product.. As a result, it's completely different,
both from a user as well as a developer standpoint to the four devices which
preceded it in the same product line, and two (three?) years late from it
original schedule. Of course, they did not scratch everything every time,
otherwise it would never have finished at all. But this, and Nokia's recent
history, should serve as a powerful lesson to us all: ignoring what has already
been created, building from a blank sheet instead, is a recipe for delay and
financial disaster.

Software is design. Design needs robust vocabulary and the processes to use
them well, if it is to create something successful.

Search

This site uses cookies to provide its author information about the visitors' reasons for their visit. It also, at time to time, plays hosts to various tests on mechanisms designed to improve web analytics, deliver content monetization opportunities, and whatnot. By continuing to visit here, you consent to tracking under EU rules. If you wish to control the amount of information available of you to site authors, you're advised to peruse aboutcookies.org and configure your browser accordingly.