Reply to: Any recommendations for bug tracking software?

[OrangeHopper]

Good fixers have the ability to grasp the big picture - what is it trying to do, how is it trying to do it - so they can quickly focus in on the likely source of the problem while having the necessary coding skills and experience to actually fix it. Not everyone has this mix or the experience.

[VectraMan]

I am not technical, but reading your posts has given me some insight into testing and Quality management. I am going to see a client tomorrow who has a problem finding programmers who will fix bugs. They want people who have C C++ and a grounding in low level languages such as Assembler. Why do they not offshore the work to India? why is it difficult to find bug fixing programmers? and why do they want people with such strong skills?

help appreciated

I actually thought about trying to sell myself as a bit of a bug fixing specialist, because delving into other people's code is something I'm good at and don't mind doing (up to a point). The problem is it's a bit hard to quantify, it's pretty much impossible to know how long something is going to take which means the traditional fixed term contract doesn't really fit, and you don't get a MSC-whatever to say that you're good at bug fixing. The other worry is that I'd get pushed towards testing roles, and I really don't want to be doing testing.

Oh and I can do C, C++ and assembler.

Fixing a bug, without just putting bodge code in place, often requires quite a lot of refactoring and sometimes attending to design flaws in the system.

That's often the case, but just as often bugs are silly mistakes or things that are obviously wrong when you find them. I spent nearly a week working on a bug for my last client that turned out to be a 2 instead of a 1, and it was completely clear that it needed to be a 1. In my experience, whilst there are the fundamental design flaws, programmers usually do a better job on making sure the big things work and it's usually the little things that get missed.

[Jabberwocky]

Splendid idea - I can work on fee per question DA or on a day rate for more in depth advice - please message me and I will give you a quote.

[DodgyAgent]

A bright idea

Thanks zeity. Maybe CUK should have a subscription only facility for agencies who wish to ask technical questions, I cannot tell you how helpful this would be.

[privateeye]

I am going to see a client tomorrow who has a problem finding programmers who will fix bugs.

Most programmers consider bugfixing as a bore and want to be involved only on new work. Its work often given unfairly to juniors as not many people enjoy it. As a release manager I would say it is one of the most important jobs and requires skills that go across many disciplines - as first you have to analyse where the bug actually is front-end backend etc etc. Most programmers just like coding but don't like the analysis work involved with finding complex bugs.

[DodgyAgent]

DP, I cannot tell you how helpful that is thanks

[DimPrawn]

Fixing a bug, without just putting bodge code in place, often requires quite a lot of refactoring and sometimes attending to design flaws in the system.

Hence anything but a trivial bug requires a strong knowledge of the architecture and design and good problem solving and coding skills.

A sensible company that values quality will put their best people into the support team, especially if the product is rather "flawed" and overly complex.

Not just some numpty in India with 6 months experience an MCSD he bought from Mumbai for $10 and a vague grasp of the English language.

HTH

[DodgyAgent]

I am not technical, but reading your posts has given me some insight into testing and Quality management. I am going to see a client tomorrow who has a problem finding programmers who will fix bugs. They want people who have C C++ and a grounding in low level languages such as Assembler. Why do they not offshore the work to India? why is it difficult to find bug fixing programmers? and why do they want people with such strong skills?

help appreciated

[VectraMan]

I must say for this type of thing I just knock up an Access Database, or even an Excel sheet, both perfectly adequate.

My old job we just used mesages in public folders in Outlook. Not a brilliant system, but it worked and everything else we looked at seemed to be a) expensive, b) a lot of effort to setup, and c) tended to dictate the way you work rather than working for you. The important thing is to keep track of everything, it doesn't really matter how. Absolutely the worse thing to happen is to have a system everybody hates so much that they try not to use it.

[DimPrawn]

I think what really works is an end to end system.

It is best to have integrated system where problems reports can be logged centrally and change requests can be raised against the pr's.

Then the source repository (version control) is linked to the cr system so that all changes and labels are against these change requests.

All code associated with cr's are reviewed by the best designers and coders in the company before being put into a dev build

The build of software is automated and preferably continuous and any source that breaks the build is flagged up.

As each dev build is made automated deployment systems move them up to test where automated test scripts probe for failures.

Once past test, the problem reports are closed or further pr's are raised.

This is how I have worked in the past and it works very well.

The downside is the cost of these end to end quality systems and the time it takes to get them up and running, but boy do you meet deadlines with ease.

HTH

[BlasterBates]

I must say for this type of thing I just knock up an Access Database, or even an Excel sheet, both perfectly adequate.

[janey]

I'm not a PM but I have been a project leader (all the hassle but none of the glory) and I worked under a PM who came from the same school of thought and salty here and I have to say I agree whole heartedly.

The team I was in (pre-the fab PM) was notorious for producing (or not producing as the case usually was) awful software. Post- the fab PM, the team became one of the strongest in the company, and was leading the way with process and quality.

I can not agree more wholeheartedly with what you say salty... I know what you say works as I've seen it in action.

I tried to take what I learnt from him into my role as proj leader and in a major company wide project my team finished our side of the project months in advance of everyone else... in fact I think some of them are still going now and this was over 6 months ago!

[salty]

It seems like the requirements document was inadequate, as were the functional specifications.

I was having this exact conversation with my boss yesterday. Requirements are by nature open to interpretation. In order for everyone to sing from the same songsheet, reviews of documentation need to be conducted- not just by the author and Project Manager- but by the whole project team.

The example you've highlighted about the absense of an error message. If the QA and Dev group were in the requirement creation meeting- this is something that would have been easily flagged up.

The message here is:

Move the QA involvement effort UP the cycle, and leave the traditional "oh, we'll do the testing later" ehos behind.

Testing for the known is a simple affair, whereas testing for the unknown is the tricky bit.

[expat]

Step back a minute and thing of what "Quality" actually means. IIRC Meyer in the late 1970's descibed it as "Meets requirements".

Saw a comment about attitides to this on the US board:

I remember some years ago when I was doing a gig for a Japanese owned company. They local management was all Americans, but they were kept on a very short leash by their bosses in Tokyo who were constantly trying to get rid of us. One day we received a report which proved that the Japanese coders were almost 10 times more productive than the American contractors.

We countered with a report that showed the code they delivered was about 5 times more likely to break, even though it had passed their rigorous testing process.

The problem was that they coded exactly what the specs said. No more. No less. For example, the spec said to present a screen with 4 choices - A, B, C, D. When the user selects A do somethihg, when the user selects B do something else and so on. Worked great. But when a user typed "E" the program crashed. We reported this simple flaw and showed them a similar program written here. When the user typed "E" it generated an error message and waited for a valid response.

They triumphantly produced the spec and pointed out that no where did it say to generate this message.

We wondered how this made it through the testing phase, Turns out this problem came up several times, but the testers never reported it because they assumed it was their own fault for not following the instructions.

[janey]

I am expensive

won't be me who's paying!

doubt the existing PM would be very happy tho.. plus he'd be the one to employ you.. doubt that's going to happen!