Re:How fair do you think time estimate within 30% is? Plus/m...
by b0rsuk on Thursday May 09, 2019 @01:53PM
(#19870477)
I do own the book.
Only the issue here is, strictly Jira-oriented programming. You only ever modify lines that fall into your ticket. You don't lint, don't remove trailing spaces, insert missing semicolons. You DO.NOT.CLEAN.UP. It's not enough to have IE-compatible code that follows naming conventions, README.md and .eslitrc (used very sparingly). You must use arbitrarily chosen existing functions, and on code review you're given very vague suggestions like "use the function we have for that", or "eh". Files commonly over 3000, 5000 lines.
Who owns the codebase? Does it belong to the client or to your boss? Is it in anyone's interest that the quality of the code be improved over time?
There is a conflict between efficiency and accuracy of estimates. If accuracy is a goal, you can improve accuracy at the cost of efficiency by giving very high estimates, then working slowly if the task turns out to be relatively simple.
The codebase sounds like a bit of a tar pit. You may be interested in reading Feathers' book "working effectively with legacy code". This describes patterns and tactics to use to get automated regression tests in place around applications, so that you can start to refactor confidently and add unit tests. You need time and support to work on these if the existing code is bad. It can be very slow going and hard work. If you cannot convince your employer to support some changes to start gradually improving code quality over time, you should look at options for alternative employment.