|
|
|
|
|
|
by iandanforth
1822 days ago
|
|
|
I like a lot of these principles but there is a crucial element missing from this presentation and that is time. As a company grows the importance of each of these principles changes. As a project within an established company grows a similar maturation happens. If you tried to adhere to all 'best practices' (principles or not) from day 1 of a project you'd be carrying a lot of weight that could crush otherwise good ideas. Some principles, when presented without a timeline, seem contradictory and that can lead to fights on teams where developers are well meaning but less experienced. I'm encouraged that this presentation includes dimensions along which you can slice the principles, but I encourage the authors to adopt a "stage" dimension as well that helps focus devs/learners on principles appropriate for 1. The stage they are in and 2. The immediate next stage. |
|
|
Teams should come up with their own list of principles which reflect the team and adopt organizational ones that make sense. As organization ones will tend to be wider in scope and less prescriptive, it should be less of a problem to adopt them.
Basically teams should decide what's right for them based on their backgrounds and the organisation should provide general direction.
The principles become more useful when they are context sensitive, so principles lists are the next big feature (i.e one for your team, another for your organization)
This feedback is really useful and will inform the design of the app. If you have a good idea Ian of what you think is useful, please let me know how I can help. I think I've grokked the basics of what you're saying, but it would be good to lock it down.