Over the years I have accumulated a laundry list of catchphrases, sayings, and principles that have helped me explain to my team members what I am trying to convey. Of course like any good Software Architect, I have documented those items into a list I hope to publish in more detail on this site. Below is the table of contents with a brief description and if I find the time and energy a link to the more detailed blog post on that topic.
Always is cheap, sometimes is expensive
As you can tell by the name of this website this is my favorite principle. Here is a Link to blog article
We never say no
As IT Professionals we should never say no to our customers. We should say no, do this instead.
Just because you can does not mean you should
This is my functional vs technical disucssion
You cannot do everything until you do something
People love to dream about the end state and complain about current state. Lets get a transition state defined to make future state a reality.
No one cares if it works on your machine
How many times I heard a developer say this. Yeah for you it works on your machine. The customer still has a problem please fix it.
If the user has a problem we have two
Get the customer back to work no matter what. Then find the root cause and never have that problem show up again if we can help it.
It’s not expensive until we see say it is
Too many times I hear people say it’s too expensive but we have not compared all of the costs to all of the options to say what is the true cost. If you want to spend a dollar be sure to save 2
It’s easier for the team to edit than it is to create
Show a team a blank sheet and it will stay blank. Put words on paper and you will get feedback. As a change driver be bold and suggest something.
Progress over perfection
It will never be perfect. Get something in the user’s hands as soon as we can so we can get feedback. Agile anyone? Good Enough Trumps Best.
Solutions over problems
Don’t just say we have a problem. Try to come prepared with approaches to possible solutions.
Imitate over innovate
Especially in the design phase of solutions. What can we already use before we create something new.
Requirements will be defined somewhere during the project
I love the joke, “You start coding, I will go find out what they want”
The only promise on a project we can make is that there will be issues
We have bugs and missed requirements. Everything else is negotiation with the customer to ensure we have a solid solution.
The value of Taxonomy
Make sure we all speak the same language
Stop The blame game
I made the mistake. Everyone happy? No can we please fix the problem?
Don’t let them take your watch and tell you what time it is
Make sure your consultants and advisors bring real value
Have a Benevolent Dictator
The buck stops where? We need to make sure someone can make the decisions to keep the team moving forward.
Change or be changed
If you want to stay idle solution design is the wrong place for you.
Understand before being understood
Listen, make sure we hear what the customer is saying. This one is mainly for me.
Beware of Actions becoming Intents
I have seen the action over take the intent way to often. Teams have rules an practices but we cant remember why or know who set them.
Rules vs Guidelines
I like to make sure I know what a rule is and what is a guideline. This narrative helps a lot if with requirements elicitation.
Failure is a road, not a wall
Embrace your failure. Learn from it, don’t do it again but embrace it.
Do today to make tomorrow better
Make sure we do enough today to avoid problems and have better ways to do things tomorrow as well. Make sure the always is a the best way.
