First post on my new home! I'd like to give the obligatory thanks to Dave and Jay for setting me up here. This place has some great neighbors, so I hope I don't lower the property value :)
Anyway, I thought I'd start off the new blog with a post I originally had on my old blog site. I'll be dragging a few more to this new site as I have time, but I think that this one creates a foundation for everything that is to follow, and lets the audience know where I'm coming from. Hopefully, I can always stick to these core values.
[original blog post, 9/26/2007]
A lot of people have been asking where I get my architectural insight, how I formulate my designs, and ultimately, how I put projects together. There are a lot of other "manifestos" being tossed about in the wild, so I figured I’d toss my own out there to start to answer the questions. To me, this is the foundation of everything that comes next.
First and foremost, this is an engineering field. As such, decisions are made using engineering principals. Anecdotal "evidence", as it is, does not factor other than to stimulate hypothesis. Something is never "better" because I think it is; it is "better" because it is measurably superior.
I will always be able to clearly articulate the reasons for a decisions. If I cannot do so, the decision is suspect and cannot be considered defensible. "Because that’s just how it is", or "That’s just the way we do it here", or "I just want it that way" is never an answer. There will be clearly stated implications, causes and effects.
The decisions must always have the capability to be expressed in terms of quantitatively and qualitatively measurable metrics. One should always be able to assess Return on Investment and Risk of Investment for any given decision. This allows for alternatives based on what the stakeholders are willing to trade off, and helps to eliminate biased decisions made solely for the purpose of personal preference.
Methodologies are projects too. They are not religions. One should never blindly follow a methodology’s prescriptions "just because that’s how it is". Methodologies that insist they are a "better way" if you just "trust them" are suspect from the start. Methodologies, just like projects, will have periodic post-mortem assessments. Any part of a methodology that works will be used and improved upon. Any part that does not work will be given equal consideration, and will be thrown out or re-implemented. If re-implementation is necessary, there must be a clear review of why it didn’t work, and a clear identification of the failures, with a clear plan of action that corrects the failures. "It didn’t work because you don’t grok it" is never acceptable. An unbiased review is always necessary. Putting a positive spin on something that sometimes works and sometimes doesn’t because I prefer to do it that way will not make it better, and is never acceptable.
Professionalism will be used at all times. Criticism will always be welcome, but criticism will never be personal. Meltdowns, impatience, and caustic reactions will never be acceptable. I will never blame others to escape my own problems or because I am frustrated or under stress. I will always take the blame on issues for which I am responsible, and I will take steps to ensure I will not repeat those problems. I will always be cognizant that meltdowns or panic on my part will have ripple effects on the team, and are things to be avoided. Conversely, leadership, understanding, patience, and proactive problem-solving will have positive ripple effects on the team. In any type of failure, the immediate action should be to quickly identify and correct the problem, not to invoke blame. Invoking blame is itself a failure.
I will always conduct self-criticism of my decisions. I will never assume them to be correct. I will force myself to prove they are valid.
I will never take the "easy way" because it suits me personally. The decisions must always be accepted as the better option for the team and for the project.
I will accept team members, not minions. I do not want a crowd of groupies who always agree with me. I am not always right. Dissension and alternate viewpoints are not only always tolerated, but welcome provided they are conducted in a professional manner. Yes-men only lead to "group think", which drastically raises the risk of failure due to suboptimal decisions and incorrect assertions that are never challenged. You are not automatically wrong because you disagree with me.
Disagreements must not hinder the project. In all cases, one should strive for unbiased decisions, because in an optimal situation, disagreements can then be factually discussed and worked out. However, there will always be cases where more than one decision may apply, and where two or more team members disagree on which to take. Team members, myself included, must always be cognizant of the impact an impasse makes on the project, and must work as quickly as possible to choose one of the decisions, compromise, or come to an agreement.
I will always be cognizant that professional pride and project success is at stake for every line of code I write.