However, I’d bet a large amount of money that the majority of users don’t do this, and instead restrict themselves to a single capital letter at the beginning, end or at word boundaries (ok, the last doesn’t matter if you’re brute forcing, but I’m not sure real “crackers” actually bother with that any more, do they?)

The other thing I wanted to add was that numbers are for worst-case scenarios, i.e. the last password that you try is the right one. I think with some intelligent ordering you can probably reduce the probability of hitting the password earlier, massively. Hence dictionary attacks, I guess!

If this fix is urgent, the developer might be in a different time zone, and therefore unavailable.

If the bug is not urgent, it might be left in the code for years, by which time the developer has left.

Bugs shouldn’t be left however, especially if they have just been created.

“in practice I haven’t ever seen any real option here. Bugs are always super urgent, and can never wait for the next sprint” Alas I have. If a non-technical manager doesn’t understand the significance of technical debt, and the bug doesn’t afect them personally, they’ll rather have new features their customers are asking for, rather than fixing bugs. In the words of one boss, “When are we going to stop doing internal stuff, and get back to doing things for our customers?”

It makes no sense to have a bugfixing team, because a team will never be committed to the creation of beautiful code unless that team also gets to see this code through all of its lifecycle, from first idea to final coding.

OTOH, assigning bugs to the individual who dunnit, as you mentioned, only leads to individual code ownership and blamethrowing. Quite naturally, people will feel responsible for code they wrote, and it will make sense to let them fix it, simply because they know it best – but never make a solid rule of it, always let the team decide. Sometimes, it’s better to find a fresh pair of eyes to look at it.

As for your second pair of options, in practice I haven’t ever seen any real option here. Bugs are always super urgent, and can never wait for the next sprint. One has to fix them in-between. The moment you try to stall them, there will always be some manager or customer harrassing you until you give in and do them RIGHT NOW nonetheless.

I agree 100% with your post :)

most of it I like the part with putting your best programmers or your worst programmers on bug fixing… but I think, when you already have “worst programmers” you should rethink your team ;)

If you put all the data access methods in one layer/set of classes, something that is not a bad idea on its own right, then even renaming columns isn’t that much more work if you write column and table names directly into the SQL statement.

If I had to rename a table, replacing references in my code would be the least of my worries. And presumably not the only thing changing in the code as mentioned. Making sure all instances of the db (UAT, various dev dbs) etc. are all updated, following the change management procedures, scheduling the release with the DBAs etc. are all an order of magnitude more work.

Interestingly there is a column in a db I once worked in called FRIST_LOGIN_TIME or something. Now I can understand the a type, but presumably the developer, on seeing the typo, instead of fixing it in the database, then had to replicate it in the code that accesses it. I do not understand that mindset.