michele.simionato@[EMAIL PROTECTED]
<michele.simionato@[EMAIL PROTECTED]
> wrote:
> On Dec 11, 11:14 pm, Vesa Karvonen
> But then I started to work mostly with code written by others and I
> changed my mind.
I guess we can't help repeating ourselves here, but I'd just like to
point out that if you've actually read my messages, it should be clear
to you that we do indeed share the experience of working (for years)
with code primarily written by others. I first started working
professionally in a team of several programmers in 1997. One of my
first jobs was to go to a clients site (abroad) and fix issues in a
program written primarily by other programmers before I joined the
company.
> At work we have to keep running a large system written by others
> with code that dates back to several years ago and doing a very
> complicate business logic that nobody remembers fully.
That would be a fairly accurate description of the kind of work I've
been doing just recently.
> If something goes wrong (as it does) we have say an hour or two to
> fix the issue, otherwise we cannot give the service to our
> customers.
I haven't seen your system, but the way you describe it makes it sound
like your system is mission critical to your customers and that things
go wrong regularly. If that is the case, then I think that you really
should invest more time into refactoring. If things really leak
regularly and you continuously need to make hot fixes with duct tape,
it means that your code base is rotten and getting worse.
> We all know that a better solution would be to refactor the system
> (as we do, partially), but a complete rewriting would require,
> according to our estimates, 10 man-years and we have 5 programmers:
> no way that we are not going to close our business for a couple of
> years.
Nobody suggested that you should close the business and do a complete
rewrite. That would be the Perfect Solution fallacy:
http://en.wikipedia.org/wiki/Perfect_solution_fallacy
.
What you should do is proactively spend more time refactoring the code
base rather than just reactively fixing bugs. How does this work? A
client re****ts a bug. While you go and fix it, you notice that the
code surrounding the bug is unnecessarily complicated. After fixing
the bug, you spend some time refactoring the code surrounding the bug
to make it easier to understand in the future.
> [...] a debugger could still save our day.
Then, by all means, use a debugger! I've never forbidden anyone from
using a debugger.
-Vesa Karvonen
|
