In-House Development

Question

The in-house system I develop and maintain (at a UK college) is always under fire from requests for new subsystems to be added, minor amendments to major overhauls and a steady stream of bug fixes from previous work.

The current consensus is that because it's developed in-house, changes(regardless of size) can be made on a whim, and deadlines usually in the negative "We need this yesterday". "Surely it can't be that big a job" is common-place.

As for tracking the changes made, I have an instance of mantis that's been in play for about a year, but as I'm the only one (of about 6) that's contributing to it, it's quite useless.

To those working on in-house systems: Is this the norm? Can it be remedied?

How would I go about putting a 'contract' almost, in place between the software development group, and the members of staff requesting the changes? Anything too overkill will just be gunned down, but not loose enough that deadlines and requirements are poorly defined and heads start rolling when a requested feature is late.

Answer 1

There is only one real solution - just say 'No'.

And if you think I'm being unrealistic, I worked for a couple of years for a UK university (Poly back then) on academic admin systems, and my almost universal response to feature requests was 'No', or 'Next version'. And my software was always delivered on time, did what was required by the business (which is really what the DES or whatever its called this week required) and nobody ever suggested I should be sacked or disciplined - on the contrary, I was repeatedly promoted.

Answer 2

You just need to implement some policies. Have your supervisors (and theirs, so on...) sign off on set policies and procedures for development tasks, including change management.

Answer 3

It sounds like you need to actually implement a software development process. You could look at Extreme Programming if you need a full-blown methodology, but that'd probably be shot down. A simplified process might be:

• staff requests change (documented in issue tracker)
• development estimates time required for change (development, not staff, must estimate)
• staff prioritizes change request based on existing workload of development
• development completes changes in order of priority

Answer 4

The best bet is to have a manager between the group of people requesting changes/fixes and the development team. It is up to the manager to say 'No' when necessary and to triage worthwhile requests.

Essentially one of a Manager's responsibilities is to shield the development team from user onslaught.

Answer 5

Do requests go right to the developers, or are there any sort of project/product managers involved?

Answer 6

All RFEs must go through the bug tracker.

You estimate time for each fix.

Management dukes it out with customers to determine which fixes get priority (i.e. not your problem).

Answer 7

I would say it's generally the norm. Making a buck now instead of making two down the line always seems to be managements priority. What they might not understand is that it will actually end up costing them more.

Failure to plan is planning to fail.

If you're just making changes on a whim then you will encounter poor design decisions that will ultimately make it even more difficult to make fixes on a whim in the future.

Where I work we do a lot of in house development (we even made our own "issue tracker" for some reason...). Management and even the IT director always want things done yesterday. I've given up on trying to design things properly and I've just started adding on to what's already there. Everyone else seems happy about it and if I don't have time to do things in the time frame needed, I just say it's not going to happen. I do my best and they can't expect anything more.

Answer 8

Sounds like you just told my life story... I'm currently working on reviving our bug tracking/issue request system. No accepting any new requests that don't come from that. and if the access is set up correctly, the managers can see what else is outstanding, and just what else you may be working on that's keeping you from building that time machine :-)

Answer 9

I'm not sure how you react to all these requests, deadlines, etc. I would first start to look at your own team (of 6, as I understood it correctly). Is there something to improve there? That team is your easiest target, because they speak the same language as you, and probably know you well.

Once that team is working efficiently, you can start saying no (like Neil Butterworth suggested). Because you've got to treat your users as little kids. They need to be educated and raised. They need to respect you for what you do (assuming you do it well).

Try to put agreements on paper (agreements that you would make usually, no contracts), so you have some leverage (it's all about leverage) at the end (or during) your project. It is important to let your users know WHAT you are going to deliver and WHEN you are going to deliver, and maybe even more important; WHAT you are NOT going to deliver.

Make bullet points out of those 3 things, and you should be alright. It takes some getting used to (for your users) but eventually this will create a better working environment for you and your users, because you know what to do, and they know what to expect. And if either of you forget, it's all written down..

Answer 10

I'm with @tehblanx on this one. Clearly this is a management failure! Anything you do is only chewing gum in a cracked dike. Change has to be implemented at a management level.

Management is meant to provide regulatory authority, to winnow requests, perform triage and set priorities, clearly that is missing from your environment.

Management is not meant to be Yet Another Oppressive Boot on your neck.

Answer 11

As stated above, your options are limited. In Cowboy Coding environments, the cultural incentive is to NOT participate in processes. While a set of processes will result in a better product, the reduction of chaos will make it easier for new people to come in and learn the product and in turn make your co-workers less indispensable.

In other words, chaos is good for hackers. If nothing is written down and nobody understands where the landmines in the code are, you become pretty irreplaceable. When new people come in and screw things up, they get to come and save the day. As it more and more people are fired and quit and labeled morons, the smarter these guys will look.

Your only hope is to put a simple presentation together for your management that will make it crystal clear how a few simple changes will benefit HIS career.