2 ms·

I fully agree with the risk that certain ideas will be overused. This leads to unnecessary complexity. I also remember the times of the GoF book and the design

I fully agree with the risk that certain ideas will be overused. This leads to unnecessary complexity. I also remember the times of the GoF book and the design patterns rage. The ideas behind those architectures require time to think through. The sooner you start, the better. Then, slowly, try adopting them. If you have a side project, then apply it over there. It's crucially important to have a common understanding of the project within a team. The domain knowledge should come from the subject matter experts, but after that it should be a team work to decide which (if any) patterns and architecture should be applied.

ams6110 13y ago
Common understanding of the project... yes that is essential. I've got a tangental role on a project right now where that is NOT happening, and predictably the system is a mess. Each developer is being given task assignments by the lead but nobody really understands the overall architecture, goals, and design of the system. I'm actually not sure the lead does either, it's really one of those "make it up as you go" projects. Sadly it'll ultimately be scrapped and have been a waste of time for everyone involved, except to the extent they can learn some lessons from it.
- andrzejkrzywda 13y ago
  It's essential, but also ... difficult. It's a peopleware problem, more than a technical one. If there's no trust in the whole team, then all the design/architecture challenges are less important. I've just read it today, a good post on this topic: "We all know Conway’s law: “any piece of software reflects the organisational structure that produced it.”. In the same way, communications patterns between people affects the quality of the software. After 6 months working on a greenfield project I realised I could link all the areas with major technical debt to some unsolved personal conflicts in the team." http://bitlyfied.com/2013/12/19/happiness-and-other-technical-requirements-lessons/ http://bitlyfied.com/2013/12/19/happiness-and-other-technica...

ams6110 13y ago

Common understanding of the project... yes that is essential. I've got a tangental role on a project right now where that is NOT happening, and predictably the system is a mess. Each developer is being given task assignments by the lead but nobody really understands the overall architecture, goals, and design of the system. I'm actually not sure the lead does either, it's really one of those "make it up as you go" projects. Sadly it'll ultimately be scrapped and have been a waste of time for everyone involved, except to the extent they can learn some lessons from it.

andrzejkrzywda 13y ago
It's essential, but also ... difficult. It's a peopleware problem, more than a technical one. If there's no trust in the whole team, then all the design/architecture challenges are less important. I've just read it today, a good post on this topic: "We all know Conway’s law: “any piece of software reflects the organisational structure that produced it.”. In the same way, communications patterns between people affects the quality of the software. After 6 months working on a greenfield project I realised I could link all the areas with major technical debt to some unsolved personal conflicts in the team." http://bitlyfied.com/2013/12/19/happiness-and-other-technical-requirements-lessons/ http://bitlyfied.com/2013/12/19/happiness-and-other-technica...