Greeting again Monks!
Thanks for all the very useful responses and links! Have a lot
of ammunition for the next meeting.
Let me try to answer some of the questions that were asked in the
responses. First of all it really still is safe to travel!
The software to control traffic consists of several layers. The bottom
layer designed under very strict procedures and safety standards. It
is designed by one team, reviewed by another, and tested by yet
another. It contains the logic, some hardwired, to make sure no two
trains can ever make use of the same track and collide.
The software we make sits on top of this layer. Since the bottom
layer is secure the guidelines for our software are less strict. If
our software fails things just stop and are delayed.
We do use revision control, a 20 year old one, but we do have a
nice GUI in Perl/Tk on top of it.
We do do a lot of testing, but only after all code is written.
To give an idea of the problems we have in our code:
- We have a coding standard but not everybody followed the rules.
- We have functions that are over 800 lines long. They did not
started out that way of course. A few years ago a function would be 60 lines
long. Then the requirements changed, and again, and again; each
developer added a few lines, and it turned into a 200 line function.
The next developer did not have time to split it into several
functions because only 8 hours were available to implement the
seamingly simple change in the requirements. So the function grew and
grew. Now we have 800 line monster functions that are hard to
maintain and understand.
- We have software architectures that worked well a few years
ago, but since they were not adapted to the evolving requirements,
they do not work that well today. In response to that all kind of hacks
are implemented to get around this quikcly, worsening the situation.
- We have the same functionallity implemented in different ways in
different applications. (Since there was no time or budget to turn it
into a library.)
A lot of this stuff, I hope, can be prevented if we get some budget
for code review. Going to try to get them to adapt the approach
suggested by dragonchild and etcshadow;
only fix and refactor the stuff in functions that were changed,and add unittests in the process.
Management is now atleast entertaining the idea of code reviews and
with this method and all the arguments supplied by the others that replied there is
some light at the horizon.
Have the feeling that we are not the only shop with this kind of problem
though :).
Many thanks again.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.