
Could software be a list of business process mistakes? - cstejerean
http://weblog.raganwald.com/2008/03/process-is-to-software-as-software-is.html
======
boredguy8
"The utility of the maxim is remembering that the complexity of the user
manual is an imperfect but helpful proxy for complexity of the [interface]."

I think you can have incredibly complex software with an intuitive interface.
I don't doubt the author agrees, but I wanted to make that point first.

The clearest visceral experience of that valuable lesson came from playing
through the 'commentary' track of Valve's _Portal_. The designers really
understood how to teach the user the rules of the game without saying, "Here
are the rules of the game in 28 pages of color photos and tiny text."
Listening to their commentary made me start asking questions as I design, too.

But shortly thereafter, I came to a more profound realization: Valve's so
successful in their design mechanism because _they never change the rules of
the game_. So often, whether in games or in applications, the 'rules' change
from one iteration of the software to the next. This creates bad code, bad
maintainability, and a bad end-user experience.

(Oh, and: I sometimes wonder if our company began it's $10 million ERP "as an
indirect way to force this review [of business processes].")

------
pchristensen
Another typical Raganwald post where he nails it so precisely that there's
nothing else to say!

~~~
raganwald
Shall I pour the 15 year-old Glenfiddich "Solara" or the MacAllan "Cask
Strength" for you?

------
edw519
"Business processes are often these gnarly heaps of rules with massive
omissions, contradictions, and bits where what people say they do has no
relation to what actually happens."

Exactly!

Which is what makes analysis so important even though it's (usually) so
overlooked. Put the right people in a room together with all of their
paperwork (actual, not samples) and keep asking questions until everyone
agrees THAT's how it works. Feed them if you must, but nobody leaves the room
until we all agree. Then go to the office, warehouse, showroom, factory floor,
or whereever and verify it.

It doesn't matter how well you can code or how fast you can code if you're not
writing the right program.

