

How many problems does this solution create? - eswat
http://dl.dropbox.com/u/506504/solving_problems_by_yongfook.txt

======
patio11
If I can make one comment, hard won from painful experience: if there is just
one of you, there are only two acceptable answers as to when you'll have
something done: "It is already done." and "It is not done." Customers tolerate
missing features surprisingly well, and if they don't there are more fish in
the sea.

Missing promised shipping dates, on the other hand, costs you tremendously
disproportionate amounts of goodwill. _Making them_ often requires stress
wildly disproportionate to the business value involved.

Example: When I started (and was stupid), if a customer asked me "Does the
software do $FOO?", and $FOO was in active development, I'd say "I'm working
on $FOO right now and it should be ready on $ESTIMATE." Often $ESTIMATE was
about a week away. Now that I'm older and wiser, I say "$FOO is not ready but
it is planned for a later version of the software. Would you like me to email
you when $FOO is ready?"

This happened not two weeks ago with an enhancement to the online version of
my software. It didn't support consistent columns yet (some users to call
bingo games by word and column, which cuts search times for players down
drastically, especially important when you're playing with older folks who
don't have great eyesight). I've implemented that in Java before and thought
it would take me less than one day in Ruby, and had a Saturday free. When I
was young and stupid I would have said "I expect to have that done on Sunday."
Good thing I didn't -- Friday I got enough overtime piled on to totally
exhaust me, and I didn't get up until 3 PM on Saturday, with a planned social
engagement at 6. But its _all OK_ because my customer doesn't know any of
this! It just took me until this weekend -- I sat down, banged it out, and
just emailed her about it. If she buys, great, if not, none of us is worse
off.

------
jason_tko
Ironically, the solution of sharing an article through a Dropbox linked text
file has created the problem of no text-wrapping, and low readability.

~~~
eswat
Apologies for the lack of formatting. Guess I need to reread this message a
few more times for my own good. ;)

Formatted HTML:
[http://dl.dropbox.com/u/506504/solving_problems_by_yongfook....](http://dl.dropbox.com/u/506504/solving_problems_by_yongfook.html)

------
Kliment
Most of the discussion appears to be about word-wrapping, but I think the
actual content is pretty important. This is an excellent evaluation strategy
for people doing you favors. "How much trouble is it?" is my first question
when thinking about something that might save me money. Annoyance has a cost.

------
chipsy
It's definitely the case that I've written programs - or just specific
features - that were wrongheaded and caused too much maintenance overhead for
the perceived benefit.

But when you're thinking in terms of an organization, the overhead of most
complex solutions can be waved away by throwing people at it. And that, in
turn, can be the foundation of a strong business - or a huge wasted effort.

------
Dilpil
Hmm, doesn't word wrap for me, and is unreadable as a result.

~~~
chipsy
View source has a word wrap option.

~~~
tome
That depends on what browser you're using!

------
lunaru
I'm often inspired by the software that Yongfook churns out (fan of Sweetcron
and Open Source Food). This just shows that it doesn't matter who you are or
how talented you are - you have to find a problem you're passionate about
solving. If the passion isn't there, there results won't be either. I think
that's another way to state the article title.

------
SlyShy
I haven't applied this principle to my daily life like he has, but it is an
important problem solving technique that I apply when programming.

Most people just call this "managing complexity". ;)

------
zb
There are some very interesting examples of this given in the book "The Logic
of Failure" by Dietrich Doerner.

------
keefe
problem #1 : poor documentation <ctrl+w>

