3 ms·
Probably the most useful thing you'll do to learn about architecture is to screw up this project. Sorry, but there it is. You can read a lot on Martin Fowler's
by angersock 11y ago
Probably the most useful thing you'll do to learn about architecture is to screw up this project. Sorry, but there it is.
You can read a lot on Martin Fowler's site about how to screw up the project. You can watch some great videos by Uncle Bob (I especially recommend "Architecture: the Lost Years") on how to screw up the project. You can even checkout some ruminations on software development by reading through old game project post-mortems on Gamasutra.
If you want advice about how to get better at this, I'd say sit down at lunch and redesign the system. Do this like every day for a week (or month, or until you stop leaving work hating the state of things). Then, go talk to the business folks and really learn how the business functions. Then, figure out where your designs failed to meet these requirements, and use that as a guide for how to evolve things.
I would say, though, learn how to pull off features aggressively and without hesitation to simplify the code. The best architecture is the one that is hardly noticed, but which, when seen, appears obvious and yet mutually exclusive with bad implementation.
- weddpros 11y agoMaybe the best way to learn is to succeed (to some degree) at this project, and later realize you could have done much better... Learn from your (small) mistakes. Maybe "su*k at it, but don't fail" beats "screw up this project". A failed project might not give you the best learning experience.
- sheepmullet 11y ago"If you want advice about how to get better at this, I'd say sit down at lunch and redesign the system. Do this like every day for a week (or month, or until you stop leaving work hating the state of things). Then, go talk to the business folks and really learn how the business functions. Then, figure out where your designs failed to meet these requirements, and use that as a guide for how to evolve things." Spot on. And to add to this you should also try to implement parts of your better designs outside of work. This will help you gain a concrete understanding of the trade offs in your design. Secondly, when you get requirement changes or feature additions at work, try and apply (even if just on pen and paper) those changes to your architected versions. Often this will give you an aha moment where you realise your favourite alternative has serious flaws.