Home > Archive > Software Engineering > August 2004 > Is this a business/job opportunity? How?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is this a business/job opportunity? How?
|
|
| Bob Rosen 2004-08-14, 3:56 am |
| I am currently working in a short-term temp job through an agency. (It does
not involve software development.) At this client company I have had the
privilege of using a data-entry system that was apparently developed in the
1980s, and the person I was reporting to there, a long-time user of this
system, remarked about how antiquated and awkward it was. Is there any
conceivable way I might convert this into an opportunity to create a new
version of the system, either as an employee or (more likely, I imagine) as
a consultant? I have never before considered trying to solicit work in this
fashion and have no good idea how to go about it. Also, I really do not
have any sales skills. Am I probably better off just letting it go?
Bob R.
| |
|
| Bob Rosen wrote:
> I am currently working in a short-term temp job through an agency. (It
does
> not involve software development.) At this client company I have had the
> privilege of using a data-entry system that was apparently developed in
the
> 1980s, and the person I was reporting to there, a long-time user of this
> system, remarked about how antiquated and awkward it was. Is there any
> conceivable way I might convert this into an opportunity to create a new
> version of the system, either as an employee or (more likely, I imagine)
as
> a consultant? I have never before considered trying to solicit work in
this
> fashion and have no good idea how to go about it. Also, I really do not
> have any sales skills. Am I probably better off just letting it go?
Lead your contact into this strategy:
- list of the bugs and feature requests
- sort them by business priority
- if a bug is internal, offer to fix it within the
existing interface
- if a feature request is external, offer to
produce a Web interface
- guess at two w 's worth of work
- program for two ws, writing unit
tests for each new feature
Emphasize this system is pay-as-you-go. They may stop the project at any
time, and keep working code with new features. You are /not/ going to rip
their system up for 6 months. They have probably experienced or read of
rewrites that make everything worse, and toast lots of money. They fear
losing control. That's why the system got so old without an upgrade. Going
in small batches, two ws at a time, lets them change the feature requests
at the end of the two ws. Ensure that, every two ws, users actually
_use_ what you create.
You must re-skin this application. It ought to have an intranet interface.
You will need a little extra time and resources to install or configure a
Web server to support new data entry forms, new reports, etc. Converting the
existing system would require a long rewrite, with a blackout. Deal with
this essentially by playing "nail soup". Promise you won't take the old
system offline until new system features can replace it. Then, for each bug
or new feature, find an excuse to upgrade the GUI as you fix the bug.
Use HttpUnit to write tests on the Web interface. They will keep your bug
rate way down.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Richard Quinn 2004-08-14, 3:56 am |
| On Sat, 14 Aug 2004 04:32:07 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
> - guess at two w's worth of work
Is that not a little unethical, taking a ball park figure out of thin
air just because it coincides with the length of a typical XP
iteration?
My worry with this kind of leading is that the believability of the
software professional takes a dive when that two w project is still
going strong, with no end in sight, after 6 months.
Would it not be better to take the highest priority tasks from the
list and estimate each one thoruoghly?
---
richard.quinn@ieee.org
www.richard-quinn.com
| |
|
| Richard Quinn wrote:
> Phlip wrote:
>
>
> Is that not a little unethical, taking a ball park figure out of thin
> air just because it coincides with the length of a typical XP
> iteration?
A typical XP iteration has a team, and there are coaches' coaches who
recommend 1 w.
So what's unethical about telling people who fear a "rip up for 6 months and
finish in 2 years" strategy that the "pay as you go" strategy is well
researched?
> My worry with this kind of leading is that the believability of the
> software professional takes a dive when that two w project is still
> going strong, with no end in sight, after 6 months.
You have no experience here. When a customer receives a new working version,
bug free, frequently, they feel in control. The end is in sight frequently.
> Would it not be better to take the highest priority tasks from the
> list and estimate each one thoruoghly?
The tasks should be small. I didn't want to lead Bob into this realm, but
one could schedule to throw the first iteration away, and use it as a
learning situation. Or one should do the first tasks in strict business
priority, during the two ws, and see where one finishes.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
|
|
|
|
|