|
|
On Sat, 16 May 2009 20:22:23 -0700 (PDT), "jeh...@gmail.com" <...@gmail.com
On May 15, 5:11 am, "Paul" <...@novareconsulting.com
I want to thank Pete and you for your encouragement. I start feel
alone in my cubical some days. My coworkers don't generally know or
care about these low-level details. For the past year or more, our
users have been using a new user interface. Every time they screw up
and leave out a field or try to recreate an existing record, we get an
email with a stack trace and the error message. We probably get close
to 10 of these a day and we only have about 11 users. In the next few
months, the number of users will probably be closer to 100. I can't
image how many emails I'll be getting then.
The problem is the way we do things: backwards. My lead developer
believes that we should let the database catch the majority of the
user's mistakes. Instead of our UI telling them to fill in a field, we
let constraints on the database handle it for us. In cases like that,
I just want to scream. The user doesn't know what an ORA-00001 error
is and a message like "Unique Contraint Violation on PK_001_CUPK"
really doesn't help them. The fact the UI doesn't handle this is
absurd in my opinion. It was al right when we only have a couple
users. However, when you start seeing the same error 10 times a day,
you know something has to be done about it.
Of course, I'm not going to take the time to write the code that
translates every Oracle error into a user-friendly message. I'm going
to spend my time adding validation to the UI. I kind of have to weigh
out what I can leave to the database and what I should check in the
UI. Unique constraints are a little impractical to check in some
cases. However, I can probably handle missing fields fairly easily. I
would like to know that when 100 users are using my system that I
still only get 10 messages a week.
This user interface was redesigned from Oracle Forms into Windows
Forms. My lead developer said to me, "The user interface will have a
clean separation of layers: a three-layer architecture."
Unfortunately, his interpretation was a little off. We have DataTables
that are created and manipulated inside the code behind. He bound text
boxes to rows in code by maintaining row indexes. Each form was
thousands of lines long. He wan't using binding correctly at all. I've
fixed a lot of it since then, but it is still highly dependent on
DataTables being in the code behind. Recently I got him to agree to
allow me to move the code I wrote for the other subsystems into the UI
(no more maintaining the code set under two source control folders for
me!). I plan to use that code to rework some of the forms that are
causing us our problems. I just need his approval. This will probably
be the week where the form completely bombs and needs fixed anyway.
Eventually, the entire system should be a little more consistent and
hopefully less buggy. I can start making the UI a little more
versitile then. I'm kind of racing against the clock: will the system
start getting used more first? or will I stablize the system first?
What's funny is that ever since I started using this new code set,
I've rewritten close to a quarter of the entire system in less than 3
months. That's 10 separate applications! That's says something for
taking the time to do design. I will probably redo the reporting and
UI side of the application and be half way. Then I have to implement
the two power bill calculators and the system will be completely
upgraded. I'm expecting the UI and reports to take about 3-5 months.
Each of the calculators could take that long, too. They are still
written in C/C++ from the 80's (global variables anyone?).
Is there any wonder why I am paranoid about making a mistake? It'll be
biting me in the butt for years!
|