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

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"?

From stackoverflow Sam Schutte

• 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.

  Sam Schutte : No - you definitely have a point. I think the trouble is that without either cold hard facts or authority, sometimes it doesn't matter what you communicate. Especially if you have other developers who are your peers that disagree, and a boss that doesn't know which person to "trust".
  From Galwegian

• 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.

  Sam Schutte : Certainly if you said - "See, half the automated tests are failing, and our code coverage shows that we only have 10% of our codebase being tested!" - that's a step in the right direction.

  Alexander : I disagree with this strong statement. Although you can use the create-a-test-for-each-bug approach (if I got your point), a bug tracking systems offers not just a list of issues, but also facilitates communication about the issues (and not only among developers).
  From David Nehme

• 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.

  From Manrico Corazzi

• 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.

  From Robert Gowland

• 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.

  Josh Kodroff : I would add that it's probably going to take quite a bit of effort and patience to see the changes in your environment that will make it easier to create the quality work. Try your best, but don't be afraid to look for a better situation if you feel you've done all you can do and your situation isn't working for you.
  From kmilo

• 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.

  From Aaron

• 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

  From meade

• 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.

  From Ian Ringrose