3 ms·

I'm cleaning code right now and do it 90% in line with these good advices. However, I differ on the over engineering issue. It is not enough to say YAGNI. With

by gbog 14y ago

I'm cleaning code right now and do it 90% in line with these good advices. However, I differ on the over engineering issue. It is not enough to say YAGNI. With YAGNI people will put a value in a new column of table, then later on they will need another one, another column, then in fact we need to know when these value where set, by who, and you get a table with 600 columns, while what you needed to do from start was a simple event table, but YAGNI, you know. So, no, you need to think carefully for some parts of your code about what the future might look like, specially for data structures and storage part. You need to avoid the many traps, and only with some careful consideration and some experience will you be able to do "the simplest thing that works" the correct way. So what is the correct way? This can be easily seen in examples: to me vim, git, Linux, gnu coreutils, python, seem to be designed the correct way, even after a long life (but git) they still have many user, the base is solid and can support many fast changing projects.

mjfisher 14y ago
I don't think that's how YAGNI should be applied. I've always found it to be a great rule of thumb provided you're also constantly refactoring. So in your example, perhaps the first column addition is justified. When it comes time to add the second column, that is the time to take a step back and think of a more general abstraction. This is because you've just proved for the first time that you actually need one. If you can't absolutely predict future requirements (and humans generally speaking are bad at this), perhaps you'd only ever have needed that one column in the first place. That way you keep a clean, simple codebase until you know a more complicated framework or pattern is required. Of course, a rule of thumb is just that; I've seen YAGNI far too religiously applied too. And I'm in absolute agreement about being careful to think ahead carefully about the overall design and architecture of what you're working on - otherwise it's easy to become trapped in local minima of your solution space. It goes without saying different projects are suited to different approaches - YMMV.

by gbog 14y ago

mjfisher 14y ago

I don't think that's how YAGNI should be applied. I've always found it to be a great rule of thumb provided you're also constantly refactoring. So in your example, perhaps the first column addition is justified. When it comes time to add the second column, that is the time to take a step back and think of a more general abstraction. This is because you've just proved for the first time that you actually need one. If you can't absolutely predict future requirements (and humans generally speaking are bad at this), perhaps you'd only ever have needed that one column in the first place. That way you keep a clean, simple codebase until you know a more complicated framework or pattern is required. Of course, a rule of thumb is just that; I've seen YAGNI far too religiously applied too. And I'm in absolute agreement about being careful to think ahead carefully about the overall design and architecture of what you're working on - otherwise it's easy to become trapped in local minima of your solution space. It goes without saying different projects are suited to different approaches - YMMV.