I have heard every excuse of why not to unit test. The most common excuse is “it takes too much of my time”. I can sympathize, but I give you one simple challenge – start counting your “Oh Shit” moments.

There are many moments you can start counting.

Oh Shit I …

• didn’t code that right (the very first time)
• just broke previously working functionality
• fixed a bug, but created another bug (or two)

How many “Oh Shit” moments would you have in a day? In a week? On a project? They can really add up. Most importantly, you can measure how much time you spent fixing things you didn’t need to.

Obviously you can also measure time spent building unit tests, but the time saved not spent on “Oh Shit” moments now becomes transparent and immeasurable.

Simple challenge – count the number of times you think “Oh Shit”. Hopefully, this small act will give you a more aware perspective of wasted time and the time investment of unit testing.

In the world of software architecture there are many “-ilities” you must take into consideration with every project. Prioritizing them is necessary because the client will optimistically ask that you do all of them. To help you out, here is a quick list outlining my top 7 default “-ilities” in the order that I prioritize them:

1. Usability

Software usability can be described as how effectively end users can use, learn, or control the system. Some questions to ask yourself to determine usability might be:

• Is there a UI metaphor that I am using to help users adapt? (for example, the ‘desktop’ is a metaphor)
• Are the most common operations streamlined to be performed quickly?
• Can new users quickly adapt to the software without help? (is it intuitive?)
• Do validation and error messages make sense?

2. Maintainability ( or Flexibility / Testibility)

The definition of maintainability [for me] implies how brittle the code is to change. As a result, I tie the terms flexibility and testability into the overall maintainability of a project.

• Does the entire team understand the code base or does knowledge islands exist?
• Is the code throughly regression tested?
• Can modifications to the project be done in a timely manner?

3. Scalability

Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage. In short, ensuring your program doesn’t slow or bust when pounded by more users than you originally anticipated.

• What is your current peak load that you can handle?
• How many database records can create until critical operations slow down?
• Is the primary scaling strategy to “scale up” or to “scale out” — that is, to upgrade the nodes in a fixed topology, or to add nodes?

4. Availability (or Reliability)

How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program.

• How long does the system need to run without failure?
• What is the acceptable length of time for the system to be down?
• Can down times be scheduled?

5. Extensibility

Are there points in the system where changes can be made with (or without) program changes?

• Can the database schema flex to accommodate change?
• Does the system allow Inversion of Control (IoC)?
• Can end users extend the system (scripts, user defined fields, etc)?
• Can 3rd party developers leverage your system?

6. Security

I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.

• Does the system need user or role based security?
• Does code access security need to occur?
• What operations need to be secured?
• How will users be administered?

7. Portability

Portability is the ability for your application to run on numerous platforms. This is can include actual application hosting, viewing, or data portability.

• Can the data be migrated to other systems?
• For web applications, which browsers does your web app support?
• Which operating systems does your program run on?

Obviously, this is not an exhaustive list. There are many many more (Backwards compatibility, Interoperability, and Reusability to name a few).

What is your “-ilities” list? Which do you prioritize over others?

Imagine this – the wrestler Triple H comes out of nowhere and slams you up against the wall. He is yelling something about you and his girlfriend.

Now [having thoroughly pissed yourself] you have to get yourself out of this situation. What personality traits would you need to survive this situation? Strength? Intelligence? Courage?

Although this is an extreme situation, inter-office battles can be just as threating, and I would deal with the situation the same passive way in the office as I would Triple H – with the 3 H’s:

Honesty

First and foremost, never get caught in a lie (you are in a bad situation so don’t make it worse), and the easiest way to avoid getting caught lying is to be honest.

Sometimes being honest isn’t enough, and you have outwardly show you are sincerely honest. Showing someone that your are sincere and honest gives the impression you are attempting to sympathize, thus making a tough situation a little easier.

Humbleness

In really bad situations, it is never good to be confrontational. Being confrontational escalates the situation because you are attempting to win, not resolve the current issues.

Try and place yourself in other’s shoes. You should be humble enough to recognize that there is a distinct possibility that your point of view is wrong. If you lack humbleness, you can’t view situations from different angles and thus lack the ability to learn from others.

Humility

For me, it is imperative to be humiliated in these situations for a number of reasons.

First, the physical feeling of embarrassment tells me to mediate more on why the situation escalated. Deeper thinking helps to determine answers for the problem today, as well as preventive steps for tomorrow.

Second, humiliation allows one to remove pretentious images of self worth.

Third, without humility you can not be humble.

Winning office battles is not about yelling matches or demolishing other people. Successful developers can deal with these situations in a calm manner while learning more about their environment, teammates, and themselves. If still none of this works, then throw a folding chair.