Timeline for What hurts maintainability?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 6, 2013 at 4:22 | comment | added | Balog Pal | I'd add KISS an especially Travel Light to the related principles list. The latter weighs more than YAGNI, that only wastes time in creation, but former keeps the thing bleeding and even carry a snowball effect. | |
| Feb 19, 2013 at 16:48 | history | edited | user39685 | CC BY-SA 3.0 | deleted 7 characters in body |
| Dec 5, 2011 at 16:18 | comment | added | Michael Borgwardt | @PeterAllenWebb: I'd say that keeping the design simple should generally have a higher priority than preparing it for changes that are likely (rather than certain). That doesn't mean you should never do it. | |
| Dec 5, 2011 at 15:59 | comment | added | PeterAllenWebb | I agree with this observation in principle, but it is less clear cut than the others. It is sensible to do a limited amount of future proofing and decoupling, especially in areas that you know are likely to see change. You are quite correct that it is possible to go overboard in this regard. Knowing the right amount to do in a given situation could be difficult to determine. It requires experience and judgement, and reasonable developers will often disagree. | |
| Dec 5, 2011 at 15:07 | history | made wiki | Post Made Community Wiki by Mike Dunlavey | ||
| Dec 5, 2011 at 11:09 | history | answered | Michael Borgwardt | CC BY-SA 3.0 |