Slashdot Mirror

Well, why are you taking with them instead of the people paying them?

Because they are the ones writing crap, and they are capable of doing better if they applied themselves a little. When people don't try, that is entirely on them. There are plenty of books they can read or even partially free ones to get better. They can go home and watch Netflix if they want but then it's all on them.

Trustworthiness and skill are orthogonal.

ok, you completely misunderstood or you are trolling. Examples.

1)A person doesn't know how to write Javascript or CSS. Can you trust this person to finish the frontend featureset by next week? No, you can't.

2)A person doesn't have good estimation skills. Can you trust this person to estimate when they will finish? No, you can't. Another example:

3)A person has finished their work within the estimate every sprint for the last six months. Can you trust this person to correctly estimate when they will finish? Yes, you can.

So.... What is the difference between the second and third example? One of them has skill in estimation, and the other doesn't. That's it. So teach that person how to estimate. There are ways to do that.

Oh mother fucker, if you have 45,000 open bugs that's clearly wrong. Maybe there's no way to do it right, but zero bugs is achievable.

If you don't fix your bugs, then technical debt will begin to pile up and overwhelm you. In fact, one of the quickest ways to judge the quality of a codebase is to look at the number of bugs in the bug tracker (of course that can be gamed also, like any metric).

I'll just assume you know a developer who disagrees with that statement, who thinks, "every project has a bug list that grows and grows."

Here are some resources to help your friend:
Jim Shore talks about how to manage the process aspects.
Kate Thompson talks about changes developers can make to get no bugs
And if you prefer blogs, there are blogs

Your friend needs to get his dev skills up to date.

Fred Brooks famously pointed out that, "If you have a small team of competent developers, any development methodology can work." 'Competent' here means largely soft skills: things like being able to plan, and reach your plan on time (or recognize when the plan will be behind schedule as soon as possible). Agile is fine, but not-agile is ok too.

Actually I've been reading through a lot of Agile consultant training lately (had to go to the training myself, too), and I see a clear divide. Some of them are focused on process.....they say, "here follow these steps and everything will turn out well." Those are garbage. The other one is focused on improving the skills of the developers, basically teaching them soft skills (here's one example). Those work better.

I was really looking to make it a teaching moment, show him that actually there are people (like Donald Knuth) who program with a very low bug count such that their bug tracker is always empty (because they have few enough bugs that they can fix them as soon as they are reported), and that there are people who even teach how to accomplish that kind of programming,

But if he's gone this long without coming to that awareness, what can I say to him that would change his mind? Is there anything? He seems too set in his ways to see anything different.

In reality, it's not the process, if you want a good team and a good product, you need to focus on improving the programmers: the process is secondary. The best Agile proponents actually do focus on improving the skill of the team, but too many of the consultants out there are focused on process, process, process,, which leads to mindless monkeys.

As near as I can tell, mindless monkeys is often the goal. Well quick mindless monkeys that produce something good enough to get the next round of funding. Last I checked, programmers were still people. Forcing people to blindly conform to process and schedule first, rather than quality just drops morale, and long term you will have worse products, and perhaps products with structural defects deep in the system because an unrealistic planned schedule was used for all the estimates.

Combine that with the truth that poor quality software can be dangerous. An innocent game could be used as an attack vector to compromise a platform. A library could be used in a military product and lead to compromise. The people that included could have a schedule, so they just made it good enough to work and moved on. Such a library could even be used in a medical application. Combine that with the possibility of using a standard Windows OS with remote access for support and you have a potentially dangerous situation.

I'm less than certain that Mozilla needs to release updates so frequently, save for security, and those should not include non security related changes. Focus on getting it right and making sure it is right. If that reduces the releases to only a few a year, but those few releases just work, and what's more, you can be reasonably sure you have a solid product that won't need a security update the next day, then I think that is preferable.

Ever since Mythical Man Month came out, there has been plenty of focus on managing programmers, on how to improve managers (which isn't necessarily bad, and MMM is a great book).
The end result is that sometimes programmers run around like mindless monkeys, following process, and trying to figure out what is wrong with their process and what change they need to make to make things better.

In reality, it's not the process, if you want a good team and a good product, you need to focus on improving the programmers: the process is secondary. The best Agile proponents actually do focus on improving the skill of the team, but too many of the consultants out there are focused on process, process, process,, which leads to mindless monkeys.

But getting back to MMM, Fred Brooks pointed out that unless you have a giant team, the exact processes you use are kind of irrelevant.

I contend that one can always learn to think more clearly, and if one is constantly doing so then one's code will constantly be less clear than one is capable of writing.

You are right, but there's a point where you are 'good enough'. Let me give an analogy:

Traffic going onto the freeway can be bad, and if it gets too bad, then suddenly there is a slowdown, or even traffic jam. If the traffic is clear, then you can go the speed limit. The traffic can become more clear, but there is a point where it's "good enough."

Of course, you should ask, "When is it 'clear enough' in software development?" I think Jim Shore has the answer. When your code is clean enough that you can operate in the sort of 'no bug' environment he describes, then there is still room for improvement, but you write good code at that point.

I really like the idea of Extreme Programming and building an app a little at a time. But I've found it's a LOT easier to have a vision of the end-goal and work towards that, rather than work on a little piece at a time as if that piece was a distinct unit.

That seems perfectly compatible with XP and agile development to me. A friend of mine wrote an excellent piece on product vision in agile development as part of an upcoming book.