3 ms·

Make it work; make it right; only if proven necessary, make it fast. Make it work is the dirty version, always comes first without thought of proper factoring

Make it work; make it right; only if proven necessary, make it fast. Make it work is the dirty version, always comes first without thought of proper factoring or abstractions. Once working and under test, it's much easier to then make it right, which is factoring out duplication and fixing up the code to be clean and well factored. Then and only then if something is too slow and a profiler shows a problem do you make it faster.

AstralStorm 10y ago
This way you end up dead really soon. The model only works for small projects. Short version rephrasing of the rule: put a prototype into production. You can see how it is obviously bad. Typically cleaning up a dirty version is VERY hard. Takes much more time than rewriting assuming you wrote proper functional tests. Likewise you cannot make a truly wrong design really fast without redoing it. I would flip the rule on the head: design so that it can be made fast, is easy to get right, therefore will work.
- blowski 10y ago
  It depends on your knowledge/experience levels. A very experienced develeoper's prototype would likely be much better than a junior's production-ready version.
  - AstralStorm 10y ago
    That is true, but mostly because said experienced developer actually has a design in mind while programming. At the very least a sketch of one. It is usually better to just write it out and discuss instead of following through based only on your own gut, however good it is.
- gnaritas 10y ago
  No, you're not understanding the context in which to apply this; this isn't something you do at the app level, it's something you do at the feature level. The app is always well structured and well factored, but when adding a feature, you start dirty, get it working, then clean it up, and then optimize it if required, then move on to the next feature. This model works for all sized projects, all the time. The point of doing things dirty is to avoid premature architecture/abstraction which is a bad habit many programmers have. Now if you have the experience to know beforehand what abstractions you need because you've done this many times, of course you can start cleaner; you do things dirty when you're unsure of what abstractions you might need and don't want to get hung up in trying to invent an abstraction before you know you need it.

AstralStorm 10y ago

This way you end up dead really soon. The model only works for small projects. Short version rephrasing of the rule: put a prototype into production. You can see how it is obviously bad. Typically cleaning up a dirty version is VERY hard. Takes much more time than rewriting assuming you wrote proper functional tests. Likewise you cannot make a truly wrong design really fast without redoing it. I would flip the rule on the head: design so that it can be made fast, is easy to get right, therefore will work.

blowski 10y ago
It depends on your knowledge/experience levels. A very experienced develeoper's prototype would likely be much better than a junior's production-ready version.
- AstralStorm 10y ago
  That is true, but mostly because said experienced developer actually has a design in mind while programming. At the very least a sketch of one. It is usually better to just write it out and discuss instead of following through based only on your own gut, however good it is.
gnaritas 10y ago
No, you're not understanding the context in which to apply this; this isn't something you do at the app level, it's something you do at the feature level. The app is always well structured and well factored, but when adding a feature, you start dirty, get it working, then clean it up, and then optimize it if required, then move on to the next feature. This model works for all sized projects, all the time. The point of doing things dirty is to avoid premature architecture/abstraction which is a bad habit many programmers have. Now if you have the experience to know beforehand what abstractions you need because you've done this many times, of course you can start cleaner; you do things dirty when you're unsure of what abstractions you might need and don't want to get hung up in trying to invent an abstraction before you know you need it.