|
Help me bring my dept into the 21st century!
This forum has been quite a help to me and my efforts and, if I may, I’d like to pose a question to the forum – how can I help bring my department into 21st century application development?
Before anyone can answer that let me give some background:
I’ve worked at various private, mature, software development companies before returning to my alma mater (a large state University) as a software developer (waives tuition so I can get a graduate degree for pennies on the dollar).
We are almost entirely a report/utility-writing shop to support (free of charge) various university entities; the poison of choice (development-wise) is called SQR. These SQR reports use SQL to fetch data from our large OLTP application, usually in the form of either PDF documents that can be printed out or CSV files which can be turned into Word Merges or imported into Excel for end-user manipulation.
SQR is not exactly what you’d call cutting-edge and has plenty of warts:
There is no such thing as object-orientation
Every variable is global by default (and working with local variables is so painful you have no other choice but to use globals)
Array sizes are non-dynamic
The only two (meaningful) variable types are ‘number’ and ‘string’ (determined by the prefix: #number_var; $string_var)
Every report that you produce is a separate program which is interpreted at runtime and produces either a plaintext file or an Adobe PDF document
The only form of extensibility or reuse is via #include “yourfile.sqr”
There is no IDE for development (TextPad or the like is the norm)
****Caveats****
Of course SQR is the only game in town. Everyone knows it, and there is ZERO chance of switching to something else (like Crystal or MS or whatever) – so please don’t waste everyone’s time by suggesting a change.
Also, I am not going to quit or leave the department in at least the short run so please don’t suggest “just leaving”. Plus, I’m a Boy Scout, and I always try and leave places I’ve been “better than you found it” so if I accomplish nothing else here it will at least be to get the department moving in a right track.
I don’t think that bringing in outside help (e.g. consultants) is an option. We don’t have the budget nor do I think I could convince upper management that it was necessary.
Finally, outsourcing is not an option. :)
****Departmental-specific (but still vague to protect the innocent) background****
Due to several factors (frustrations with SQR, University (i.e. low) pay, clients abusing the “Can’t say no to clients” policy, etc.) department turnover is relatively high, so anyone with significant domain knowledge ends up leaving after a few years and we have to relearn everything about software development.
We’ve been writing SQR code here for about five or six years – most of which is still being used in production. Most of this code has been written without any sort of code standards or outlook to the future.
Most of the past developers have not been formally trained in CS and so have made naive choices (sequential instead of binary search, no use of modularity, no use of arrays when logical, etc.). Also most of them were self-taught in SQL so bad SQL abounds – thus resulting in abysmal report running times (we’ve re-written programs which resulted in a run time of thirty seconds vs. forty-five minutes).
p.s. I’m not trying to imply that us CS grads are inherently better programmers but I highly doubt that someone without a CS degree is going to independently invent QuickSort. If a CS degree provides nothing else it requires you to study solved problems and their algorithmic solutions. :)
We come up with areas of concern in meetings but as soon as we leave everyone seems to forget about them and so they never get done or even thought about again.
When I came on board the number of full-time developers had dropped to one (!) and now there are almost a half-dozen of us. They had no such thing as source code management and we’ve since implemented such software to help manage the code a bit better.
I think that is sufficient background – on with the initial question again, slightly re-stated: how can I help bring my department into 21st century SQR application (reporting) development?
****Bulleted Problem List****
Large (maybe 250 separate reports) code-base of inefficient programs written/edited with varying styles and competencies
Initial developers no longer around and programs are poorly documented, leading to excessive time spent on human parsing of code
Have no standards for program “correctness” so incorrect programs often produce faulty data for ages until someone on-the-ball notices
Hard to keep domain knowledge in house
Significant institutional inertia to keep going as in the past
Clients need things “yesterday” which lead to the feeling of helplessness and so there is little urge to devote time to anything resembling review/rewrite of older code
Mediocre support from upper management in achieving organizational change
In short – we’re a -1 on the Capability Maturity Model.
****My ideas****
Obtain buy-ins from upper management (how?!)
Develop an IT “Mission Statement” which says what we are here to do, what we are expected of from clients and also what we expect from clients
Develop and enforce SQR and SQL code-standards
Define acceptable run time limits
Formally train developers on SQR and SQL if needed and require that new developers have at least a good knowledge of SQL before hire
Implement formalized code review sessions – in a weekly meeting we go over (using the results of a diff on before/after code) every change we’ve done to code which will go into production.
Reconcile increased demand from clients to internal standards; if need be try and find additional IT staffing or develop applications to handle trivial stuff
Work with clients to help understand and identify their needs so that we aren’t contacted tomorrow for data they needed yesterday
Finally:
Formulate a formal IT “strategy/roadmap to wellness” or IT Bible which we will rigorously follow to bring us out of the pain and suffering and keep us on track for the future
Of course, I recognize that many of you have perhaps gone through this process before so any ideas you have is greatly appreciated (I’ve heard of some sort of ISO-9001 standard or somesuch?). In the least, you’ve identified what works and what doesn’t, and that’s helpful, too. Thanks!!
Me
Monday, March 1, 2004
Great googly moogly... longest post ever?
Who're the Chefs?
Monday, March 1, 2004
Alright, here's my suggestion, from someone who has never actually been in the position to try this, so take it with a grain of salt:
Refactor. The first step is a comprehensive breakdown of the code base. It sounds like you've got them using some form of source control, so kudos to that. You should analyze what you've got before you go any further.
Then you go about finding commonalities in your code and make no changes that break anything - which means writing and using unit tests. Collect the commonalities and eliminate redundancies. Use your code control to unwind changes if you have to, but you shouldn't have to.
As you refactor the code, put it into logical layers so that even though you are not yet bringing in any new technology, you can do so gradually at a later date.
Yes, it sure sounds like I'm suggesting a total rewrite, but not all at once - not from the ground up. You have an actively used system, and the changes should be so small and incremental that it does not interrupt the workings of the system.
Lastly, your superiors (and anyone else resistant to change) should be convinced that this is just simple code maintenance, which it is. Maintaining something means keeping up to date, after all.
Again, take this with a grain of salt, but I think that if you do it this way, they might find themselves in the 21st century by the end of the decade.
Aaron F Stanton
Monday, March 1, 2004
I think your first two ideas don't have a prayer. Sorry. You could try rephrasing them or getting to those objectives in another way, but as you state them currently I think most people in a Uni IT dept would likely roll their eyes (to put it politely!).
Make the code reviews optional at least at first, until people actually see the benefit. Slowly slowly...
One thing occurs. You say there are problems with this language you are using. Would it be possible to implement a wrapper language around that whose "compiler" basically generates decent SQR? It might make an interesting side project for your team if nothing else.
Tuesday, March 2, 2004
Refactoring sounds like an interesting idea -- the problem as I see it is that DBMS coding is difficult to re-factor.
For example -- if you have a whole bunch of little functions which call a single SQL statement like this:
function get_address(int ID)
{
sql:
select *
from address
where id = ID
}
function get_name(int ID)
{
sql:
select *
from name
where id = ID
}
You end up with terribly inefficient code. It's far, far better to have joined the two tables together (although this example is not the best):
select *
from name n
inner join address a on a.ID = n.ID
So in effect we have a lot of little procedures like that which can be somewhat handy for newbies (since they may not know the table structure yet) but for anyone who has been here any time they join the tables together.
There still is a lot of non-SQL code in there, so maybe that can be ‘refactored’ into something nicer although none of us have any experience with XP and/or refactoring so some study would have to be done before effectively undertaking such a task.
What I’m thinking is that it might be beneficial to dynamically generate (string together) SQL based upon the programmer’s needs. Instead of calling ‘get_address( 12345’ they would call:
$address_sql = get_address(“join_column”)
Then in their main SQL they would have:
SELECT *
FROM foo
WHERE foocol = 123
$address_sql
That way we still have some modularity but it’s creating efficient SQL code.
Me
Tuesday, March 2, 2004
Thanks for the advice, uh, 'blank'. I think that writing some sort of wrapper (I assume something like C or Java since it has to run on UNIX) would be outside of the scope of our dept -- I have significant experience in C++ and C# but no one else does, and if we develop such a tool then *someone* will have to maintain it after I leave...
But I agree that things should be taken slowly -- however we've taken such a glacial approach with just about everything here that *nothing* ever gets done.
Me
Tuesday, March 2, 2004
Unless the people you work with are complete dead heads I suspect you might be able to get them interested. Surely YACC would be a better choice than writing in C/C++/Java/whatever though?
Tuesday, March 2, 2004
What I find at first sight is:
a> wouldn't it be nice if we could keep the clients at bay
b> all existing code here looks ugly and inefficient
c> we have no process, and are a fulltime firebrigade
What can you do?
a> You have no leverage. What is more, it is extremely likely your whole department has no leverage. Think about it: What will happen if your dept. head starts stalling the clients and shielding the dev. team? Will she be replaced? Will your whole dpt. go on strike to rescue her ass? This is academia, so we're probably talking feudal age dependency structures and the solidarity levels for below those of a bunch of crack junkies in need of a fix, right?
b> But it works. Sure there is the occasional problem, but it produces the reports. Leave it and prioritize elsewhere.
c> Start climbing the process ladder yourself, and convince your colleages by example, not by rethoric.
Begin by stealing a little. Each day you secretly jump of the firetruck for 1 hour and spend your time on presonal process improvement. After a while this should start to pay of enough so that you repay this original "debt" through increased productivity.
Just me (Sir to you)
Tuesday, March 2, 2004
> Obtain buy-ins from upper management (how?!)
What do you need upper management for, exactly? You're one of 6 developers: and developers (and perhaps not upper management) know how to do development. Why not just talk with your peers, and reach consensus about what you'll do collectively?
> They had no such thing as source code management and we’ve since implemented such software to help manage the code a bit better.
Yes: I'd suggest doing some more of this "we" stuff.
Christopher Wells
Tuesday, March 2, 2004
Thanks for the replies.
Let me clarify – it would be nice to have IT management buy-in to refactor/retrain/rewrite/code-standards/etc. because it obviously means that we’ll have to take some time which would’ve been spent on development of new reports and instead spend them on that. So, the mgt needs to buy-off on the idea that a little time spent here and there will reap rewards in the future.
And I don’t expect clients to have tasks put ‘on hold’ or otherwise have their requests ignored until we ‘get our way’. That’s not at all what I was trying to say.
What happens now is that event XYZ will sit on someone’s day planner for months and the day before the event they’ll call up and want a batch of data that takes a long time to compile and verify etc. If they had notified us earlier we wouldn’t have to drop everything we’re doing to get their request turned around so quickly. Further, when your plate consists of ten such requests and you only have X hours to do them in, you either are going to try and rush and skip verification steps (“That ‘looks’ right, ship it!”) or something is going to be late. Requests for more lead time is usually ignored or never honored.
On our side, we’ve started cataloging user requests – that way we can more adequately prepare for user XYZ dropping a huge task on us.
If the client who is requesting some data won’t give us more heads up on when they’d need something then we’d at least like copies of their calendars so that we can see when they are planning on something that might involve us. Given the task of voluntarily giving themselves more work or ‘forgetting’ to give the calendar we all know what happens – which is why we’d need *their* managerial support (or at least some sort of formal process that every time XYZ gets added to their calendar we get an email about it) to ensure that we receive calendar updates on a timely fashion.
We actually have a calendaring system which ties into our main database quite nicely (that way we could simply report off of that) except we’re the only ones currently using it. If people would schedule their events in this system we’d have no problems, but again this goes back to the whole ‘more work’ scenario I outlined earlier and the need for higher support.
And as far as the old code goes – I’m not convinced that it ‘works’. Any request for extending an older report results in terrific headaches and *significantly* increased resolution time for even trivial requests. And, since the report is never fixed, we have to pay again and again for past mistakes.
We’ve seen that on better-designed reports adding something else to the report is not nearly as problematic.
Further, a report whose run time is forty minutes impacts everyone from end user to programmer. We have a self-help web interface to reports where people can find reports and run them either ad-hoc or on a schedule. This is great except when they need a report in twenty minutes for a meeting and the report takes twenty-five to run. And even though it wasn’t our fault we still get chided for having slow reports (and given the ability to make them run in seconds instead of minutes I agree that part of the problem is ours).
And it becomes my problem when I have to modify that report. Due to SQR’s goofy, inconsistent print position logic output rarely goes where you expect it to (10 print positions doesn’t always equal 10 font spaces, so you have to manually line things up). Of course, you can’t tell the alignment is wrong until you run the report, so you have to twiddle your thumbs for forty minutes (or find some other little short-term thing to pop into) until you can see that your new output runs into some other existing output. Lather, rinse, repeat – and you’ve now wasted a few hours on something that could’ve taken ten minutes if not for the lag.
Me
Tuesday, March 2, 2004
p.s. I typed that on my lunch break ;)
Me
Tuesday, March 2, 2004
> it would be nice to have IT management buy-in to refactor
I've found a developer rarely gets management buy-in to do that (that is, unless your manager is experienced and/or a senior developer).
Perhaps I wouldn't mention that I'm refactoring. I'll just say "Well this is complicated: it would be nice if I could do it in 10 minutes; but in fact it will take me two days. If you don't like that, then I can not do it at all ... we'll refuse that job, or you can find another developer who can do it faster than me." This gives me 2 days in which I can refactor the thing as I deem necessary to implement the new fntionality, as well as in whch to implement the new functionality.
> And I don’t expect clients to have tasks put ‘on hold’
I certainly do. One thing that a manager does for me is buy me time by arbitrating between user requests. "Chris is busy doing X and Y at the moment. He won't be able to do your Z until next week. Sorry, I know that Z is important, but so is X and Y: if you want Z done sooner, then you should ask me earlier. Our typical turn-around times for requests like Z are currently ...".
Christopher Wells
Tuesday, March 2, 2004
> 10 print positions doesn’t always equal 10 font spaces
Oh man, don't /ever/ get involved in writing printing code for Windows ;-)
Wednesday, March 3, 2004
With repeated patterns of "fire brigade work", you either tell clients that yes, their work will be late, or else you are agreeing to ridiculous work loads for your team (or shoddy work). One or the other.
We have a fair bit of that here... one solution we use when we are doing something for person X and then person Y shows up with an "emergency": get X and Y into a room together, lay out the possible timelines (work for X then Y, or Y then X, or both at same time with half the attention), and then leave the room while they duke it out over which timeline they want. They can't agree? Default: Go on with what you were doing (X) and tell Y when s/he can expect their delivery.
One thing to be vigilant against -- clients who DO give you reasonable lead times, build in buffers against unexpected bugs, etc, can easily end up getting shafted by your team unintentionally. If everyone else's job is an "emergency", theirs always looks like it is lower priority... that is NOT how to reward clients who are behaving the way you want! Be sure to give the "good" guys a reasonable delivery schedule and then STICK to it, no matter what other "emergencies" may crop up.
Good luck,
Biotech coder
Thursday, March 4, 2004
 Recent Topics
Fog Creek Home
|
