Re: Data driven people arguments

>Suggestions?

Out of curiousity: which kind of "activity of working on various
tables" is that, without being business logic?

I would start not being religious (I don't claim you two are, but
"holding the position" is a suspicious ;-). The point I think both of
you want to achieve is to minimize the cost of some future change. Your
colleague is concerned with the cost of redeploying and the cost
incurred in possible bad performance (perceived or real). You are
concerned with the cost of future understanding of the code (to fix,
maintain or enhance, I suppose) and/or duplicating logic (that is, the
cost of *not* reusing stuff).

First thing, you can assess if any of these costs (or benefits) are
real or perceived: for example, is a redeployment truly necessary? Is
it imposed by the technology? Can we change the technology? Will the
flow be really clearer? Will reuse have a chance to actually occur? Is
the software going to be maintained or is a one-off? And so forth.

This assessment depends on your context - not just the software
engineering context, but the broader picture: company, design of the
software, time to market,etc. It also helps to try and be clear also on
the assumptions that you guys use during the assessment - for example,
you think that there should be reuse (because it gives value to the
company/customer), and your colleague think there should be the
possiblity of redeploying with a 5 minutes downtime (because it gives
value to the company/customer).

You'll probably find that you have lots of common goals, and maybe
you'll find clever ways to satisfy goals that initially appeared in
conflict (like, for example, to *both* redeploy fast and have a clear
control flow).

However, sometimes these goals will really be in conflict: you cannot
pay lesso to achieve one goal without paying more on the other. At this
stage, you need to evaluate the cost/benefits from a nontechnical
perspective, either by yourself (if you manage to agree with your
colleague) or possibly using the mangement - which is payed exactly for
taking these calls. Of course here the subtle art of presentation
matters, but I won't go further into that. ;-)

By doing so, you'll end up with a "business prioritization" of your
various conflicting goals - which allows you to take decisions on which
goal is more important, and a more or less shared understanding on
_why_ you're deciding the way you are. Then go implement these
decisions.

The next important bit is the feedback. Once implemented, keep on
measuring if the decision you take has produced results according to
the prioritization above. Document this quantitatively (say, recording
how many redeployments occur in a six-months period, how many
enhancement requests etc) and figure out the impact they had to the
goals. If they don't match - lesson learned for next time.

Now, on the specifics: it doesn't matter where you put or how you build
it - so long one piece of logic sticks to one responsability,
maintenance will not suffer. So as a compromise you may go for stored
procedures, but NOT in adding responsibilities to an existing one.
Being able to change things in production without any bureaucracy is a
mixed blessing: it allows to react very fast, but also to screw up very
fast. Think of using techniques, like test-driven development and
continous integration which help keeping things in order independently
from the allocation of responsibilities among technologies.

If you feel that your colleague is being unreasonable, bring in a third
part if possible.

.

Relevant Pages

  • Re: How do you make decisions that optimize software quality?
    ... >> ...mandate that you must deliver software at the absolute lowest ... >> possible total cost of development and deployment... ... Clearly it should be the goal of a built system ... If they are chosen after goals ...
    (comp.object)
  • Re: How do you make decisions that optimize software quality?
    ... >> ...mandate that you must deliver software at the absolute lowest ... >> possible total cost of development and deployment... ... Clearly it should be the goal of a built system ... If they are chosen after goals ...
    (comp.lang.java.softwaretools)
  • Re: Days not weeks
    ... A programs success is determined by whether it meets its goals. ... is not a goal then cost is not a success criteria. ...
    (rec.sport.golf)
  • Re: Days not weeks
    ... A programs success is determined by whether it meets its goals. ... is not a goal then cost is not a success criteria. ...
    (rec.sport.golf)