Timeline for How to distribute development and bug fixes tasks
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 21, 2023 at 16:37 | history | protected | gnat | ||
| Dec 21, 2023 at 16:36 | answer | added | UserOfNet | timeline score: 1 | |
| Dec 21, 2023 at 14:02 | comment | added | sleske | As to what to do - have you asked your developer? What do they think? You should consider their input. | |
| Dec 21, 2023 at 13:53 | comment | added | sleske | @JacquesB: Sorry, but as an absolute rule that is stupid. Some bugs are severe showstoppers, others may only be minor annoyances. A new feature can absolutely be more important than a bug - that must be decided case by case. Also see Should I intentionally break the build when a bug is found in production?. | |
| Dec 20, 2023 at 21:05 | answer | added | gnasher729 | timeline score: 5 | |
| Dec 20, 2023 at 19:23 | answer | added | Frank Hopkins | timeline score: 14 | |
| Dec 20, 2023 at 19:10 | comment | added | Frank Hopkins | @JacquesB unless that development is to redesign something to be less likely to "attract" bugs, currently the developer might just patch one small issue after another without being able to look at a bigger solution... but I guess you meant feature development? | |
| Dec 20, 2023 at 18:39 | history | became hot network question | |||
| Dec 20, 2023 at 17:15 | answer | added | Ewan | timeline score: 13 | |
| Dec 20, 2023 at 16:14 | comment | added | JacquesB | If you have a single developer, and there are enough bugs to take all this developer's time, then you have a serious problem. You should stop development altogether until this is under control since new development will (inevitably) introduce new bugs, making it impossible to keep up. | |
| Dec 20, 2023 at 12:43 | vote | accept | Cap Barracudas | ||
| Dec 20, 2023 at 12:11 | review | Close votes | |||
| Dec 25, 2023 at 3:04 | |||||
| Dec 20, 2023 at 11:42 | comment | added | Jacob is on Codidact | I've made similar complaints myself. The demotivating part was not fixing bugs (which is development work), but rather 1) being directly exposed (and seemingly accountable) to the expectations of users who had been sold something we were not delivering, and 2) having to work around significant limitations in a product we were not really able to change. Make sure you are solving the right problem. | |
| Dec 20, 2023 at 11:34 | answer | added | Hans-Martin Mosner | timeline score: 18 | |
| Dec 20, 2023 at 11:32 | comment | added | anon | Always fix bugs first, see Spolsky's classic piece: joelonsoftware.com/2000/08/09/… (point 5 is the relevant one). | |
| Dec 20, 2023 at 11:10 | answer | added | Philip Kendall | timeline score: 8 | |
| Dec 20, 2023 at 10:39 | history | asked | Cap Barracudas | CC BY-SA 4.0 |