Tag Info

New answers tagged

4

The reason you don't see those surgical software teams that much is explained by the way developers are hired and assigned to teams. Two preliminary conditions for such team are: That there should be, within a company, developers who have different levels with an important gap between the most and the lest experienced ones, And that they are ready to work ...


-4

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best ...


2

The purpose of developers is not to "write code". The purpose of ANY engineer, be they software engineer, civil engineer, or whatever is to SOLVE PROBLEMS. Therefore, it IS possible to judge a developer on their work, but not in any of the ways that you listed (sort of...). Number 4 is on the right track, but not quite complete. Judge developers on how ...


2

You will find that it is nearly impossible to plan the work down to the granularity that you are proposing. If you want to have the flexibility to respond quickly to changing requests from the business, while still giving the developers the stability that they can finish what they are working on before being asked to switch to a different task, then I would ...


31

You cannot measure and you cannot quantify. Give those ideas up from the beginning. Peopleware goes into great detail about how some people offer value simply by being catalysts for the rest of the team. Those people must not be dismissed because they're not producing lines of code. Likewise, we've all worked with developers who churn out work but are so ...


8

You measure it by spending the hours necessary to manage the project. If you wait until all is said and done, you have no way of pulling statistics out of the final product. You can't even look at the artifacts of the process and measure the contribution levels automatically without falling back on the naive statistics. As progress is made during the ...


4

All of the measures you propose are naive and bad, however, some are much, much worse than others. Specifically, the first three are very bad - in fact, trivially subverted. Only the last one - implemented functionality - should even be considered in a business decision. Obviously this measure lives and dies by how well the "functionality measure" maps to ...


0

Don't outright say no as that would hurt his feelings. Just make it clear that due to technology constraints that 60% of the time it will work every time. And once he realises the impracticality and cost involved in such an undertaking, suggest a more practical approach within his budget such as having a setting that allows you to change text size. And the ...


0

Low-quality QA is wretched, and if you can't get Management to recognize that they're not doing their job, that's even worse. But the only person that's going to be blamed for intentionally putting in a terrible bug is you - for wasting everyone else's time, and for putting in a bug that, if QA is as bad as you say it is, will go into production and ruin ...


1

I think this is the critical part of the issue here: I was working on a rather large and important feature. Critical part the of feature was that users could get a discount under certain circumstances. Problem that we had with that project was that QA was very sloppy and missed a lot of important bugs. On the other side project manager had a lot ...


7

Is it good idea to test testers by leaving bugs or even creating them? No, you don't want your employees playing petty games about who can stump who, rather than delivering actual value. If your QA department is not delivering value you likely: Have a company who assumes testing is not worth paying for and hires duds for QA roles Don't have ...


0

The first two issues you mention are not that hard to resolve: If you don't want your users to create redundant subscriptions, then you can make sure that for each task you can find which project it belongs to. Then you can use the following logic for the subscribe/unsubscribe button if user is subscribed to task's project, then disable or hide button ...



Top 50 recent answers are included