New answers tagged

1

The single best thing you can do is introduce some standards. Everything you say is caused by a mess of "do whatever" appearing in the codebase. Keeping this concept of "add some more cool tech (eg EF migrations...)" will only add to the problem. You need to reduce the scope of maintenance, not increase it. The best way to do that is to start to reduce the ...


0

You get into trouble when you try to be too literal or adamant about anything in software development as much as we all really want things to be cut and dry. Bugs should get fixed before new features are added, but I would still consider the importance of each when making this decision along with the scope of the problem. There are exceptions to everything. ...


0

This is a very common problem, no matter how fast a project is advancing on technical terms the client perceives it as going much much slower and feels free to change requirements as they like thinking that the developers must not be doing much anyway. This flawed perception comes from three major development tasks that consume time and will never be ...


0

The simplest way is to stop thinking that Scrum is agile and use a slightly different (and better - everything is better than Scrum :) ) methodology such as Kanban. You do not need a burndown chart to be agile, and you do not even need to be "on target". Burndowns are really there solely as a tool to help you determine how much work you should be able to ...


-2

I use an IDE to refactor code. It does a decent job, but gets it wrong sometimes. I also do whole codebase regex search and replace, and I often get them wrong too. I use my revision-control software (or diff) to show me what changed in the codebase. It happens often enough I check diffs now whenever I let my IDE do the refactoring.



Top 50 recent answers are included