I worked for a company that had some problems in this regards. The
project timeline would be determined before any coding estimates had
been given. And you were expected to make it work. The standard
development cycle was to code everything without a lot of help from the
user base and then when you were done, you would make all the changes
required by the users. The analysts would not get firm requirements up
front and would use the testing phase to see if the users liked the
screens. When they didn't the developers would work a lot of extra
hours. Especially because the deadline was fast approaching. It wasn't
unusual to find developers required to work weekends the last couple
weeks before the deadlines. The final testing and code review really
suffered.
So, this kind of thing does happen. This companies culture ensured that
this type of behaviour would continue. The IS staff (developers) were
constantly frustrated by this approach, but the user base was generally
happy, so it was considered a success and repeated with each project.
Generally when a project was split into phases, phase 2 would never get
completed... To get over the users anger about this, the second phase
was renamed to phase 1.5. :) Ah.. Good times!
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Ron Power
Sent: Wednesday, August 22, 2007 7:58 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: MVC Architecture and transactions
I don't normally get into debates, but I have to put in my two cents for
what it's worth based on the comment:
"I won't try to make excuses for soft code, but I will say that time
constraints placed on projects significantly limit the developer's
ability to "harden" their applications. These common pressures result
in immature code that is prone to failure. (This is, of course, an
issue for management to address...)"
If I as a developer allowed code to be put in place that allowed
failure, I'd have my a$$ handed to me by my fellow developers, not to
mention management. I for one cannot, for any reason, see any excuse
for an application that is not buttoned down completely. Time
constraints or otherwise, I think it is foolhardy to release an
application that is not ready. It is better to be late and have a solid
product, than to be on
time with a buggy one. How many of us have complained about Microswift
and there buggy code. And as far as time constraints go... that is the
fault of either the PM or the developer for either not giving themselves
a proper timeline, or allowing the project scope to be changed too much
without adding extra time. I don't buy the whole "we didn't have time
to test it" bit. Thus, if the application is developed correctly, you
shouldn't have issues with the data. Now the only way the data can be
messed up is through another source, such as directly accessing it.
So, what Joe says is correct, if you can't control the data going in and
coming out of the database, and have security around the database setup
so that end users can't DFU data, then the database is doomed. If you
let users DFU the data, or delete or insert records that cannot be
verified thru the application, then you are doomed to have application
issues when the data is extracted and used.
Of course, this is only my opinion....
Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
709-576-8132
rpower@xxxxxxxxxx
http://www.stjohns.ca/
midrange.com
