Best practice knowledge across some of the various development disciplines I work in.
When it comes to making decisions as a team, the goal should be to reach consensus. The leader can allow the team to “dare to disagree”, and also guide the team to consensus. If we have 5 experienced developers, and we come to a point that we all agree that X is the best way to design and develop it, there is a very high probability we have made the right decision. If one of us doesn’t agree, let’s keep discussing this until we do. Ultimately though, as the leader, I’ll always have to sign off on the approach.
Consensus is the power tool of good Dev teams.
Software Development – Waxing Philosophical
The customer is not always right. You are their partner, and you need to guide them into making the right choice. Don’t spoil them, by saying yes when it’s not right. Over time, they can turn into a brat, and that’s bad for them and you.
Give a monkey a rope, and he wants to be a cowboy. Be careful when you agree to do a small thing for a demanding person; it can become a very large thing quickly.
Nine pregnant women can’t have a baby in a month. Developing software requires completing predecessors in earlier interations. No, you can’t get it all at once, sorry!
Under Promise, Over Deliver. Managing expectations is job #1 when working with the customer; manage well and everyone is happy.
To Thine Ownself be True. Be fair to yoursef. Outcomes are maximized for everyone when it’s Win-Win.
Focus and Execute. The left and right hands of the mighty developer. Make it happen baby.
There is no Fate, but what we Make. Just ask Sarah Connor; you make the future, take control.
Confrontation == Progress. To solve big problems you can’t be afraid to confront people and bring them to the light. You must break some eggs to make your omelette, or else your stuck and nothing happens. Embrace Confrontation!, it is a mighty tool for good.
Don’t puke in the punchbowl. People remember your mistakes 10x longer than your successes; do your best not to make them.
Somedays, it’s your turn to be in the barrel. Sometimes it ‘just ain’t your day’; no worries, tomorrow will be a fresh start.
Consistency == Sanity. Always use your turn signal, even when there is no traffic. Always have consistent habits in naming conventions and in processes, this makes for a simpler day, and a better quality result.
Do or Do Not, There Is No Try! Heed the instruction of Master Yoda.
Certain Victory. Rally the troops, knock down all barriers, leave nothing to chance, and assure certain victory.
Low Coupling, High Cohesion. Well designed architecture will strive to minimize coupling between classes, components, services, applications, and so forth, so that changes in one part of the system don’t break other parts of the system. High Cohesion simply means to have everything be very good at one, and only one, purpose. (ex. no super classes). Like database de-normalization, sometimes high coupling is allowed for performance reasons, but it is the exception, and should be done only when intentional.
Ref: Key Principles of Software Architecture
Additional: Patterns and Practices Article: Cohesion And Coupling
K.I.S.S. The driving principle of software design, and life in general. Keep It Simple Stupid.
Favorite Quotes (related to Software Development)
Success is a menance. It fools smart people into thinking they can’t lose.-Bill Gates
“We made the buttons on the screen look so good you’ll want to lick them.” – from The 100 Greatest Steve Jobs Quotes (DTW: now that is passion, I Love it!)
“We don’t get a chance to do that many things, and every one should be really excellent. Because this is our life. Life is brief, and then you die, you know? And we’ve all chosen to do this with our lives. So it better be damn good. It better be worth it.” -Steve Jobs
There is absolutely no relationship between
- the required behavior of the system (Customer World expressed in use cases),
- and how you are going to implement the solution.(Software World expressed as a working system)
These are 2 different worlds. The Architect straddles the line between these 2 worlds -Juval Lowy
An architecture is described with properties, contracts, components, etc. – this is the static aspect.
How these interact should be described (UML Interaction diagram) – this is the dynamic aspect.
Coding is marrying the static and the dynamic together. -Juval Lowy
Don’t design against the requirements, they will change. Instead, design an extensible architecture that can meet the needs of the 3 – 4 core use cases.
All business systems usually have just a few true core use cases. There will be a limited set of building blocks required to satisfy these use cases. The configurability
of the system is immaterial, it’s the modularity that’s important. The Architect selects the right building blocks, then when the requirements change (as they will) you
do not change the static composition of the system, rather, you change the dynamic interaction. When done correctly, Workflow basically IS the dynamic interaction.
-Juval Lowy (on DotNetRocks)
There are three kinds of people: People who make things happen, people who watch things happen, and people who wonder what happened. To be successful, you need to makes things happen.-James Lovell, Commander of Apollo 13
People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.
– Steve Jobs