Too early implementation

Aaron Watters aaron.watters at gmail.com
Sat Apr 18 21:47:13 EDT 2009


On Apr 18, 7:48 am, Filip Gruszczyński <grusz... at gmail.com> wrote:
> So, do you know some good methods to prevent myself from just starting
> coding (which I like very much) and do some thinking about the problem
> (which I like a little less ;-))?

There are a lot of ideas, some you've seen earlier
in this thread.  Below is a sketch of the
approach I prefer.

1) Know exactly what problem you are trying to solve.
Describe the problem to the client and make sure the
client agrees with your definition.

2) Code up the solution in the simplist possible way.
(Document the strategy with an architectural outline, maybe).

3) Write tests to exercise/debug
the code and make sure you solved
the problem.  Also demo the "prototype" to
the client and make sure the client agrees
you solved the problem.

Usually at this point the first time through
you realize that you didn't
solve the problem, or didn't solve the right problem,
so you should start over at (1) ideally making
use of the bad implementation you have for reference
only (except for parts which can be included
without modification).  [Thank yourself you didn't
try to "optimize" your wrong solution and that
you implemented it in the simplist possible way.]

If you did solve the right problem then...

(4) Okay, now you solved the problem. Do you need
to optimize anything?  If so, optimize, using the
test cases to make sure your optimizations don't
break anything.  If not, you are done: don't
optimize anything.

(5) Now document your APIs, and other
interfaces.

(Ahem).  For example WHIFF
    http://whiff.sourceforge.net
is a descendant of a lot of libraries
and tools I've written to help me and people
I've worked with build web sites over the years.

It's been some months but I
think I started/restarted 3 times before
I was happy with the basic approach and could
move forward past step (3).

  -- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool

===
Software time estimation rule:
How long could it possibly take?
Double that.
Switch to the next higher time units (days..weeks etc)



More information about the Python-list mailing list