It seems like a backwards concept sometimes, but the greatest strength in anything is understanding the weaknesses of an environment. This can be something in life, in sport, and in what we want to talk about here, in technology.
When doing business and systems analysis it is equally, if not more important to understand and document the limitations and challenges that a system will have at implementation. Quite often we wish to only tout the positive side of things and to be a proponent. The truth of the matter is that the best way to show the strength is to know the reach and limit of anything.
If you’ve done anything mechanical then you have probably seen, used or at least heard of a torque wrench. It’s a simple wrench with a gauge showing the amount of pressure being applied to the bolt as you tighten it.
In your car engine manual there are tables of torque ratings for many nuts and bolts. How did those numbers come to be known? Analysis, testing, documentation and the understanding that knowing a part of the engine has a limit of torque is positive and necessary.
There are two ways to find the limits of a product or process:
- Run it in production until you find out
- Test it until you find out before going to production
Take a guess which is the better methodology to adopt? It’s not really difficult to grasp the concept. What is difficult is being able to add extensive, repeatable, measurable testing into your day-to-day product reviewing.
Two Kinds of Testing
There is feature/functionality testing which is the most common, and then there is also load testing. We focus on feature testing primarily because it is the simplest to measure against the requirements of the application or infrastructure design specification.
While feature testing is obviously necessary, and the most important of the testing types during design, we must also test for the capability of the system to handle load. This is done by using feature based testing and building the test load up to measured capacity and testing until failure.
Why failure you ask? We can only know the capacity of a system by knowing the point at which it is crippled by the load we apply to it. Just like we would find the tensile strength of a material; by pulling it with an increasing force until the fundamental structure is broken down.
There is no Bad Design
The art of design is just that: an art. There is very certainly a scientific aspect to the design process, but as they saying goes “there are many ways to skin a cat”. The key to becoming a better designer is in the ability to find all of the wrong ways early and develop the “right” way through knowing where the limitations are.
There are numerous ways to design for the requirements. It takes a little sprinkling of common sense to really find out where we may have weaknesses in the design process.
There are many ways to achieve a goal, and with systems and application architecture we are given many tools to reach the desired result, and we need to do our best to incorporate historical capabilities, current requirements, future requirements and of course to know the limits to any components and to the overall design.
Test Driven Development
In application development there is a methodology known as test driven development. As each feature is designed, an automated test is created to be able to repeat the process and get the desired output, or if it were to fail, to identify which part of the system was affected.
The phrase that matters there is automated test. In case you haven’t already been involved in automation, this will be a great way to add it to your arsenal to solidly validate your designs.
I’ve written before on the concept of Test Drive Infrastructure which was meant to open up the use of TDD methods in infrastructure deployment. Being able to effectively test through automation and monitoring tools is the ultimate key to shorter design and test cycles with better long term results.
If you aren’t able to decrease the testing cycles, you risk that testing will be removed from the life cycle and the result will not be pleasant. Trust me, I’ve been the one who has had to say “this will not go well” and then I am also the one who has to sit in the room when the system fails and the “I told you so” option is never really an option in a post mortem meeting.
Forgiveness versus Permission
Have you ever heard the phrase that its easier to ask for forgiveness than it is to get permission? This is usually tied in to the process of circumventing change management to put things into production because it is probably easier to sneak something in and then explain that it works, than to get the buy-in to make the steps to move new features into production where they may be risks associated.
I certainly don’t condone the bypassing of process, but this can be a part of the design process as well. There are points when a design has to be less democratic in order to get past the “analysis paralysis”. In this case it may be necessary to move forward with a design in order to begin putting through the processes of testing to validate, rather than spending too much time in pre-test design looking for the “perfect” build.
Can and Should are Very Different
We’ve all heard the phrase “Just because you can, doesn’t mean that you should”. During design we have to be very aware of this. There are lots of opportunities to use techniques that will not be appropriate for the ultimate goal of the situation.
The design process is challenging, but if we have the goal in mind to locate the weaknesses in the design and test process, it will give us a much better overall understanding of the final implementation. This takes practice, repetition, experimentation and the truth is, that it requires the ability to let it be wrong sometimes.
It is better to find that weakness in the lab than to watch your application take a dive when it is under load on it’s production launch.