Written by There are certain concepts in putting together a successful software solution that have been added to Essential To Do list, I won’t even call them best practices. They are Essential To Do really, and it’s amazing how often how these get lumped into “Well, in an ideal world, yes we will do that.” I wonder if they would take the same approach if they had an infection but were late for coffee with a friend “Yes, well, in an ideal world I would disinfect it so that I could save my leg, but you know…”
by http://www.sxc.hu/profile/danzo08
What Could Possibly Go Wrong?
One the Essential To Dos is to stop for a moment, step back, and look at your architecture from a supportability and troubleshooting perspective. When we build this system, how will we be able to know if it is not working as it is supposed to, and what are the essential human processes that go along with it. There is little point in sending out alerts if you don’t have the log files, and there’s little point in creating log files if they are not kept and no one looks at (or analyzes) them on a regular basis.
If you don’t take the time to stop and look at things from a “how am I going to get under the hood of this best” then you are going to really wish you had when things aren’t going right, and trust me, that point always happens. Sometimes it will only eat a weekend and lots of hours, other times it will become a permanent feature of the system.
It’s Secure Because I Said So
Another Essential To Do is looking at things from a security perspective, and that is a really loaded thing to say, I know. But understanding the different levels of sensitivity of the data your storing, and hunting for any time you hear “Yeah, but I’m sure company ABC stores this data, as a matter of fact I KNOW they do, and they don’t have a problem doing it.” Why hunt for those? Because it’s usually part of the argument of not spending any time, effort or money on putting any security on a solution.
As a concrete example a couple of years ago I was working with a client who was storing Visa numbers and I was asked to look at meeting Visa’s required standards for doing that. I analyzed it, determined a solution, and presented it back to my customer. The changes we would need to make were reasonable, and it was a business essential to have the Visa stamp of approval. When the client looked at what needed to be done, they really just went lazy on it, and said “Well, you know, I really can’t see us having an issue so you know what, we’re going to pass on doing this.” Wow, from business essential to “don’t bother” in about a week. Now, let’s step into it a bit further.
What actually happened is that the client, when they realized that there was stuff that they were going to need to do in order to meet the Visa standards, started to think that maybe, just maybe, they could be liable if they didn’t have security all over the place. That they could be shown to not be ignorant of such measures and instead be negligent, and that would be a bad thing in potential court, right? So, instead, let’s do nothing. Feign ignorance and march on according to industry standard practices (of which of course there aren’t any).
Shh, of course we like quality, but we like dates more!
When I worked at Microsoft we really engrained the idea of a Zero Defect Mentality in what we did. You can laugh or snicker all you want, but the idea is that there wasn’t an idea of a Good Bug or an Okay Amount Of Bugs, zero was the only happy number. I’m sure some would have argued -1 would be better, but that’s a different thread of discussion.
I keep running into situations where architects or the technical team have an opinion of what should be happening or where things should be going, but they really don’t say anything to stop the direction they helped initially set in motion. Very few, if any, want to wave their hands and say “Okay, over here! I learned new things, and I have a new opinion because of that.” Instead people prefer to act like the politicians they often despise, which is to stick to their guns no matter how little sense it makes as you go forward.
Many times I have planted my feet and pulled a “YOU SHALL NOT PASS” putting my job on the line so that a serious issue or set of issues gets properly discussed. Without exaggeration we shut down an entire project team of 60+ developers back in 98 for a week, which I have to say freaked our customer out but nowhere CLOSE to how much it freaked out our management. Trust me, pretty quickly everyone was happy that we did it because we delivered a face saving means for everyone to change their opinion.
I actually suggested to a client that they consider offering an amnesty meeting, where people can either anonymously submit or maybe just stand up and say the crazy, corner-of-the-brain, thoughts that they have that could be in conflict with any of the accepted wisdom to date. Doing this on a regular basis should get people more in tune with their real opinions, and for those that keep flip-flopping with I Told You So… those you can fire because they are just CYA people and you’ll be able to see it more easily.
Whatever you put the focus on, consciously or not, is what your team will optimize for. If it’s dates, then don’t be surprised to find that the doors are glued on, the tires are bald and the engine? Well, you said you liked the twin-squirrel engine right? …
