Responsibility without Authority is Meaningless - a technical-based solution?

Question

My dad always says "Responsibility without Authority is meaningless".

However, I find that as developers, we get stuck in situations all the time where we are:

• Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
• Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
• etc.

Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....

But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?

---

***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?

Answer 1

Sorry for not answering your question directly, but...

I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.

In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.

If anything, technology has caused the attrition of direct face-to-face communication.

Sorry, I'm off on a tangent again - feel free to downmod.

Answer 2

You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.

Answer 3

Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.

Answer 4

As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?

As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.

The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.

For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.

Answer 5

All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.

Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.

Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.

You can find more advise about this in the PSP and TSP articles of wikipedia

After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.

Answer 6

The simple answer is -- you can start using the tools yourself.

Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.

And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.

And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.

If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.

Answer 7

If you want a report about quality and it's impact on productivity - here's the best: http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking

Answer 8

If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.

However double entry has been in standard usage by accountants since about the 13th century.

It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.

So, sorry I expect we will have to face this type of problem for many year to come.