Improving Work Procedures - Programmer To Developer Woes

Question

I finally plucked up the courage to go and formally complain to the heads about my boss. What's really scary is that the claims I have made are serious enough to be taken to the CEO in a couple of weeks. I've been asked today to procure some documents referring to some points I have outlined and wanted some real-world developer input on these points.

The following are things I have raised as a part of my complaint:

• We have no formal architecture. We use code-behind only, and code-behind is what's used to open database connections, and pass SQL queries in with parameters. There are literally thousands upon thousands of pages. I propose at the very least a three-tier architecture, but I'd rather use MVC architectures. How does this ad-hoc approach affect work towards large web systems?
• We have no documentation outlining all our processes and how things work. What kind of impact could this have on us as a team and individually? Does it slow us down? (I believe it does in a considerable way)
• Bug tracking. We use none, despite bugs flowing in constantly every day. Need I say anything more?
• Testing. We have no formal testing methods, we just use TIAS.
• Usability. It's an intranet system used by hundreds of people, yet none of us are trained in UI development (in fact, I'm the only one who improves usability based on my UI studies)

I'm not asking anyone to write any of it, but if anyone has any statistics, or evidence-based facts to help improve my report. Already I've been quoting out of many books I read to use.

Just as a side note, I am the only person employed who has any formal education in what we do. We're a team of programmers, I have a degree in Computer Science and currently studying a masters degree. So from a "personnel" point of view, does anyone have any tips? I realise there are many-a-people here whom are far more experienced developers than me, so your input is greatly appreciated.

Cheers!

EDIT

So I wrote a very, very long e-mail to the management. For those of you who were wondering why I'd taken it to upper management as opposed to my immediate manager whom assigns me all my work is that I have previously raised the issues and they've been ignored.

Many points you all raised were very insightful so I decided to change my approach. Whilst I may have been hot-headed about it initially I decided to instead work on building as opposed to tearing down and stated that the changes could and would only have to be made incrementally. They were rather suggestions as opposed to statements slating our current systems. I've been recommended to raise these issues in my upcoming appraisals directly to my boss on a one-to-one basis, this is far more suggestive than getting someone else to do it.

Answer 1

I think you're onto a loser, to be honest. You aren't going to change those problem all by yourself, you're just going to make your life more difficult. The best thing you can do is find a position elsewhere where your skills will be put to use, and where you will be learning more. The team you are working with are never going to improve to the standard you are expecting.

UPDATE:
I've had my wrists slapped for this response, perhaps rightly so. As a result I thought I'd qualify it better.

I'm not saying that anyone in your position should immediately jump ship, I'm saying that based on the extent of the issues you described and your relative lack of experience and time with the firm, you will have at the best a hard job, at the worst an impossible job.

You need to decide whether to:

• Put that energy into the firm you work for just to get up to a basic standard.
• Find somewhere that meets your expectations better, and put the same energy into making it even better still.

You just have to pick your fights.

Answer 2

Sounds like you score 0 on the "Joel test". This is a good place to start to look for info to backup your arguments:

http://www.joelonsoftware.com/articles/fog0000000043.html

Answer 3

As I see it, you don't need any technical advice, you need advice on how to "sell" the changes you wan to your organization. You're probably right in that the best way to sell it to upper management is by citing numbers (which I can't help you with).

But don't underestimate the necessity to sell your idea to middle management and other developers, who may be comfortable with the way things are, perhaps because it gives them opportunities for individual heroics.

To these people you need to stress the concrete benefits your proposed changes will have for them, ideally with examples from your projects: no more users pissed off by having to report the same bug for the 5th time. Less chance of having to work overtime on Friday evening due to a catastrophic regression bug overlooked in testing. No worries of having your holiday cancelled because you're the only one who knows their way around one particular convoluted piece of the app that needs a new feature.

There may also be people who have had bad experiences with documentation-heavy processes and now see all formal development processes as useless overhead. To these, you should probably stress the more lightweight, flexible nature of agile development methods like Scrum and XP.

Answer 4

Neil may be right, but maybe not all is lost. I've often seen this type of situation and they are regularly - believe it or not - just based on ignorance.

If that is what's going on in your case, and:

1. the team is willing to learn (and to accept lessons from you - you'll probably be the one that will have to get in the role of teacher/formalizer). You'll also have to "sell" your ideas to the team.
2. management believes in your approach and is willing to support you morally as well as financially (for e.g. analysis, retrodocumentation, implementation of a bugtracker etc)
3. you're willing to put in more than some extra effort

it can be a very rewarding task. Not easy at all, and probably slow-paced but rewarding. On the other hand, especially when 1) or 2) are not present, I'd start looking around for greener pastures.

Another question: what's the age distribution of the team? Are there team members that are accepted as "gurus" by their peers? Because that's where you typically start 1)

EDIT: as you're still quite young, I strongly advice you to find a "partner" somewhere higher up the food chain. You need his support but also his advice on how to translate your legitimate technical concerns into language CEO-level guys comprehend. I'm also sure that he'll know better than you where their "buttons" (the stuff that triggers a CEO's interest) are and how to push them.

Answer 5

Wanting to change this situation is admirable, and kudos having the courage to bring it up with your management. However, I think it will be damn near impossible to make all the changes that you 'should' in one go. You'll have no visible return to the business whilst you sort things out. What's worse - without a clear line in the sand of what 'better' actually is you may end up chasing your tail for weeks on end while you figure out what your setup should look like. Set small goals for your improvements and build up incremently.

Start by finding your biggest pain points and align these with the businesses needs. Does making changes take ages because you have code replicated in several different web forms? Explain to them that changes/additions will be faster and easier to implement once your codebase is structured better.

By the sounds of it your quickest win is going to be getting some sort of bug tracking software installed. Just go ahead and do it. I ran Redmine off my own PC for a few weeks as a demo of how useful it would be. Took me a couple of hours while I made ruby gem jump through the hoops of our corporate firewall, but well worth it.

Once you have bug tracking in place, you'll have some solid evidence for backing up your opinions that your process/code need improving. Approaching management with "look at these bug reports, 50 developer hours were wasted fixing bugs because of XXXX" is going to fly a lot further than "this code sucks".

Answer 6

When selling to management, it's often a good idea to try and get some idea of money in there. I don't know what your software does, but if you can take an example of a serious bug, or one that may be likely to occur due to lack of testing and say, "If this happened in a live environment, these people would be unable to do X, which would cost Y and it would also cost Z developer hours (approx). to track down and fix".

Make it scary (but honest), and it may well help.

Answer 7

The bad news: being the messenger is a dangerous task (aka don't shoot the messenger) The good news: there are many ways to deal with it. Trick is not to become responsible for everything currrently wrong. You may want to take responsibility in improving though. Think of the role you want to play in that.

Some points to look for:

• why is it important for the CEO etc. to have this architecture, procedures, bug tracking etc?
• what questions can you ask?
• stick with the high level issues. Not having an architecture is a problem. Selecting the right architecture for your work is the next step.

Your CEO is propably interested in long term goals. You can show your concerns (!); that you see a mismatch between daily work and reaching those long term goals. Can you come up with questions to which 'architecture', 'procedures' and 'issue tracking system' are the right answers? - for instance: do you often see issues caused by many people working on the same files? Are people talking about the same component if the refer to xxxx ? Architecture can help. - are people working on the issues with the highest priority? Who sets this priority? Has everyone got the same view? - If you can link your observations to the priorities of your CEO, you'll be sure to get his full attention. Asking (a few) open questions is a powerful way to do this.

Your CEO is propably interested in seeing the status of a project. For that, you'll need to have a clear picture of work in progress, quality (i.e. bugs) and work to be done (i.e. a backlog of features and open issues).

Some things to watch out for:

• try to stay away from blaming people. It will make your position weaker; those above your project leader will propably know where to find him. Instead: address the situation.
• try to stay ayay from complaining; it may backfire. Instead, show your commitment by expressing your concerns; underline the company goals.

Another word of advise: sort out the priorities; what is #1 #2 and #3? Make sure you get the attention to the top issues.

Good luck!

Answer 8

Always remember these are problems with the process, not people. Be very careful not to seem like your stabbing your boss in the back!

Why is it that you have failed to convince your boss that these are good ideas? Should you have gathered evidence for him? If you can not convince your boss what are the chances of convincing the company heads?

I've tried making change within an organisation before; it is not an easy task. I managed to gain the support of my boss and he helped me along the way. It is going to be so much harder for you having alienated your boss and whoever his allies are. Is there any way you can rescue this situation?

Answer 9

I don't have the numbers you're looking for.

I will say these things:

1) more formal is not necessarily better. Docs and documented procs and the rest are not necessary in small teams where people work closely together. Agile teams in particular have very little written process or phase boundary docs. Informal can work with the right balancing practices (which you don't seem to have). Maybe introduce balancing practices instead of formality is an option.

2) "95 Theses" approach often does not work. Can you lead a ground-up revolution instead by setting up a git or mercurial server for code (sell as "safety net"), use TDD to make yourself faster and more bugfree and then share it, start a wiki and document what you've learned, set up a quickie bug tracker?

Most people don't need to be convinced they're wrong. They need to be shown what is right.

Tim

Answer 10

"How to Win Friends and Influence People" by Dale Carnegie has some suggestions that may be useful for your appraisal in terms of how to get your way in some cases.