[]RSS

About Archives Artwork Comic Contact Philosophy Projects Tags

A web development process

[Comment]

September 7th, 2008 in Micro Blog

I’ve been gravitating toward web development in the past few years. If anyone is curious, here is my basic approach to web site (and web application) development:

  1. Concept: do interviews, write stories about the site/application, create & collect storyboards, sketches, swatches, metaphors, and ideas
  2. Pitch: redraft storyboards and organize other materials into a final set including basic requirements if software is needed
  3. Plan: milestones, resources, inter-dependencies (only if the $ or scale requires it)
  4. Design: site + URI maps, basic visual design, information design, software design
  5. Analysis: review design, prototype tough bits, capacity analysis, reflect, and improve as needed
  6. Bootstrap: server setup, source repository setup, shell out software and content
  7. Development: short, minimalist development (simple styles, skip color + bling, simple implementations, simple code)
  8. Finishing: a small amount of review, refactoring, reflection, and improvement (only enough to get off the ground)
  9. Release: start internal, limited beta, public beta, version 1, etc.
  10. Spit and polish: make things shine
  11. Repeat: goto 8 until version 1, then continue incrementing as $/time allow

Notes

  • Web development only differers from other software in how easy it is to release quickly
  • Some of these items can be skipped, depending on the size of the project
  • Many of these items can parallelized with the right people, or when stalled on preceding items
  • Too much parallelization becomes chaos (must balance it)
  • You must release before polishing, even if internally
  • Internal (and beta) releases must be real … if you fake them, the results are useless
  • Milestones are critical to finishing, in that you need to finish the project in stages for psychological reasons (or you may never finish)
  • Analysis cannot be skipped, even if short (capacity, data, information, etc.)
  • If you’re developing framework, then you’re project will fail: focus on your goal
  • Use the simplest tools possible: paper, pen, wikis, existing libraries, etc.
  • Metaphors, swatches, and examples are cool, and are cheaper than visual-design from scratch

Enterprise software is a social, not technical problem

[Comment]

September 20th, 2007 in Links

Here’s an interesting post arguing that “Enterprise software” is a social, not a technical, phenomenon. I’ve seen many companies pulled under chasing the elusive “enterprise” features, never really figuring out what they are. If it’s truly a social problem, then we should treat enterprise requirements as a marketing problem. Then we can obsess over features from the technical side and focus on actually helping people deploy in larger setups.

Quote: Knuth on small steps

[Comment]

September 18th, 2007 in Quotes

I firmly believe that computer science advances by thousands of people solving small problems, which go together and create a massive edifice. Every year that goes by, hardly anything is done that appears to be a milestone worthy of mass attention; yet after five or ten years pass, the whole field has changed significantly. – Donald Knuth

Death to synchronization

[Comment]

September 9th, 2007 in Links

The Best Synchronization Is No Synchronization, an interesting essay proposing an alternative approach to to to semaphores, mutexes, and CRITICAL_SECTIONs.

An interview with Mr. Iwata

[Comment]

September 2nd, 2007 in Links

An interesting, longish interview with Mr. Iwata (president of Nintendo), which focuses mostly on how problems and solutions cluster in counter-intuitive ways.

Tool churn, a Windows problem?

[Comment]

August 21st, 2007 in Micro Blog

I’ve noticed a strange thing about developing software on Windows. I’m always on the lookout for good tools, as the operating system doesn’t provide any itself. Windows ships with a reasonable kernel, file system, and barely passable window manager, but that’s about it. Text editor? Terminal emulator? Remote administration tools? Development tools? Archive tools? Scripting tools? What it has are marginal, and you have to hunt down anything even close to reasonable … and even then it’s a crap shoot.

A good terminal emulator, shell, packaging system, and scripting environment are what I miss the most on the platform. does a good job of porting some of the familiar *nix tools to Win32, but they’re warty, and always feel out of place. Combine Cygwin with an improved terminal emulator (project home), though, and you end up with something workable. Window management is still a dog, and the Visual Studio, while housing a great compiler and debugger, takes some effort to coerce into a professional, automated, multi-platform build environment. It’s all doable, but man does it lack finesse.

But that’s us developers: idealistic, perfectionist, and occasionally cranky.

Skill, imagination, and art

[Comment]

August 17th, 2007 in Quotes

Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. –Tom Stoppard

Raving and Palm OS

[Comment]

August 9th, 2007 in Quotes

The Palm OS uses Mac-style tap-and-drag selection and persistent scroll bars, but (a) a stylus is far more precise than a fingertip, so their scroll bars are thinner, not thicker; and (b) no one has raved about how cool the Palm OS is since the ’90s. –John Gruber of Daring Fireball

(it’s funny because it’s true)

Book review: On Writing

[Comment]

February 3rd, 2007 in Micro Reviews

[stars: 5] On Writing: A Memoir of the Craft (Stephen King). A motivating writing HOWTO wrapped in a downright interesting autobiography. The life story is worth the price of the book, as it’s both an insight into a great novelist and an inspirational tale of addiction and healing.

Better programers learn tangent stuff

[Comment]

January 30th, 2007 in Links

Become a better programmer without programming, some sensible insights into what makes great developers.

Next page [>>]