

The Nike Software Engineering Process - mmaunder
http://markmaunder.com/2007/the-nike-software-engineering-process/

======
dhouston
all of those processes arose precisely because "just do it" doesn't scale.
even for a small team, things like functional specs and other plans can save a
lot of suffering (e.g. joel spolsky's 'painless functional specs' and other
writings -- <http://joelonsoftware.com> )

~~~
mmaunder
Functional specs are like business plans - time consuming, rapidly made
redundant and extrinsic to the street fight of running a startup.

~~~
dhouston
"Programmers and software engineers who dive into code without writing a spec
tend to think they're cool gunslingers, shooting from the hip. They're not.
They are terribly unproductive. They write bad code and produce shoddy
software, and they threaten their projects by taking giant risks which are
completely uncalled for."

<http://www.joelonsoftware.com/articles/fog0000000036.html>

i agree that you shouldn't be writing three-ring-bound tomes, but spending a
few hours planning out exactly what the thing will _do_ (just the 'what'; not
even the 'how') usually teases out problems that you'd only find a few weeks
into winging it.

~~~
mmaunder
Joel's background is Micro$oft and Yale. He has a traditional approach to
software engineering. MS is not a hub of innovation and never has been:

[http://online.wsj.com/public/article/SB116490323676636989-Hn...](http://online.wsj.com/public/article/SB116490323676636989-HnHPKLzkyy9xKy2wnokbd2bc_bE_20071130.html?mod=blogs)

Here's Dave Winer in that WSJ article:

"Microsoft isn't an innovator, and never was. They are always playing catch-
up, by design. That's their M.O. They describe their development approach as
"chasing tail lights." They aren't interested in markets until they're worth
billions, so they let others develop the markets, and have been content to
catch-up. This worked well for them in the 80s and through the mid-90s, when
they were a more nimble company with stock options that were attractive to
bright young people, when Bill G had something to prove, and was current on
the latest technology. Maybe it still does work (obviously I have doubts), but
it sure isn't innovation, in any usual sense of the word."

Scoble from the same article:

"I agree that they don't do big things that are innovative, and this leads to
disconnects as to what innovation is." [Typical ex-microsoftie trying to
change the meaning of the word innovation]

Google's dev mantra is "release early, release often". There's an important
business reason they do this - to get apps out in front of the customer very
early to find out if there's any interest in them at all. Most of the apps are
Beta and many of them have horrible bugs. If that makes them gunslingers, then
I'll take my chances as a gunslinger.

The problem I have with your last paragraph: "but spending a few hours
planning out exactly what the thing will _do_ (just the 'what'; not even the
'how') usually teases out problems that you'd only find a few weeks into
winging it" is the following:

Sometimes you don't know what's possible. If you sit down and write an english
description for a few hours, you're only drawing on your existing knowledge.
I'd rather my developers sit down and write code for 3 hours to see if
somethings possible. That way they may come up with a completely original
idea.

You're focusing on finding problems with software rather than creating
something new and useful and potentially ground-breaking. There's a time for
finding problems - it's called QA and it happens after product already exists.

Writing software isn't hard. For a good developer it's just as easy as writing
a spec. JUST DO IT!

Mark.

~~~
dhouston
maybe i'm getting trolled here :) but i don't see how joel's background makes
his points less relevant: \- it's easier to fix problems on sketches/paper
than in code weeks later \- specs cut down on amount of communication needed
-- especially with outside stakeholders \- and help with schedule estimates,
etc.

sure, in your typical web 2.0 app, many things are easy to re-work, but others
(e.g. end-to-end unicode support/other i18n issues, scaling, schema design,
etc.) are better baked in from the beginning (just ask friendster.) or at
least be cognizant of the tradeoffs you're making and budget time to throw
away your prototype.

also, google and ms have pretty rigorous software engineering processes and
tools (hell, they hired GvR just to write a code review tool.) sure, in the
early days it was probably looser. but not zero structure whatsoever -- the
total free-for-all that "just do it" implies -- hell, even "release early and
often" is a kind of software engineering discipline.

there are benefits to cutting corners (i.e. the zero planning implied by "just
do it") like getting to market faster for certain kinds of startups (early
market feedback, etc.) but these come at a cost later on! i like dharmesh
shah's idea of 'technology debt':

[http://onstartups.com/home/tabid/3339/bid/165/Development-
Sh...](http://onstartups.com/home/tabid/3339/bid/165/Development-Short-Cuts-
Are-Not-Free-Understanding-Technology-Debt.aspx)

and your assertion that QA is something that happens only after a product
already exists is equally misguided -- you can save a lot of time overall by
thinking early about how to structure and instrument your code to make it easy
to test.

if your response is 'well of COURSE you'd think about all these things up
front', then that's not really 'just do it', is it :)

~~~
mmaunder
I have some experience with this. My business is <http://linebuzz.com/> We
wrote the first line of code on April 1 and launched on May 10. We were
covered as dot-com of the day on 100shiki.com in Japan and within days we had
users in 15 languages on the site with no I18N support out the door.

<http://www.100shiki.com/archives/2007/05/linebuzz.html>

3 weeks later we launched an I18N release. Our customers stuck through the
whole thing and worked closely with us to make LineBuzz work in their
languages and charsets. Here's the story if you're interested:

[http://markmaunder.com/2007/lessons-from-three-weeks-of-
inte...](http://markmaunder.com/2007/lessons-from-three-weeks-of-
intensive-i18n/)

Many of the I18N issues we solved we only discovered because we had a large
group of international users working with us. Things like the shift_jis
character set not round-trip mapping to unicode. Not the sort of thing you can
anticipate on paper.

If I had to do it again, I'd do it exactly the same way. Next time we may
discover that the app is only used by english users and the urgent need is to
fix some privacy issues.

Most companies that plan everything out on paper tend to have a large number
of non-technical folks. MBA's and the like. When you're building a consumer
web business, your business plan is expressed as a piece of technology. So why
not just create the technology instead of talking about it. And instead of
using english to describe your business, use Ruby or Perl or PHP or Java.

Mark. ps: Sorry you feel you're getting trolled.

~~~
Goladus
Joel isn't an advocate of "plan everything out on paper." It's more about
discipline and attacking a problem as effectively as possible.

It's true that his advice does tend towards shrink-wrapped software, where
it's not so easy to just go in and fix something after you've had real users
testing it. But what you describe is closer to what he'd call "hallway
usability testing." That doesn't rule out a spec as a valuable component of
the development process.

Anyway, the test for the value of a spec really shouldn't be taken after just
4 months.

