So shit hits the fan

So after weeks of hard work you release your work into production. The release is fine, then users start to use it and then... you inbox gets slammed with bug reports and your phone is ringing with angry people on the other end. What you released wasn't working properly and people are getting mad.  This is natural because at the end of the day they paid for it and it is not working.  You would get mad too!

What to do... what to do? Freaky out? Panick? Get angry? Have you ever dealt with customer service and they were rude or unhelpful? You probably got even more annoyed with the whole experience as a whole. What to do? Be calm and try to listen to your users. If they are swearing at you, just try to be constructive and get them to demonstrate the issue to you. Keep these interactions going for as long as you need to get all of the information on the issue, then tell them that you will look into the issue and this is going to be treated as a high priority.

1. This will buy you some time to investigate the issue
2. Don't forget to keep people updated of your progress
3. Try to figure out within 30 minutes if a fix can be done quickly or a work around is possible so that the necessary paperwork or steps to rectify the problem can be initiated.

Be prudent to test more in the future to prevent this case from happening again. Even the best tech companies release things into production with bugs (ie. Apple iPhone 4's antenna issue), but it is how you deal and manage the situation that will separate you from one stupid product to a respected product. Afterall to err is human.

Why doesn't it work?

Sometimes you are in a situation where you get requirements and it is all confirmed by end users and your business analyst. You head off merrily delegating tasks and breaking this requirement into smaller chunks and work on delivering the solution.  Once done, the end users say what is this? Why does it work like this? This is a classic example of a waterfall creeping into an agile world.

Things you can do to try to safeguard yourself

1. Get requirements early and reviewed with everyone in the team
2. Rapid prototyping. Everything is good in theory but sometimes when you see it in front of your face it is not exactly as you imagined. This is the same for business users. Fail early, fail fast and improve upon it to come up with a better solution.
3. Don't be afraid to show progress even if it is something small. Many small wins are better than one massive fail. If you were able to do something minor like being able to upload data, show people, this might lead to discussions of how it would be stored and data retention questions. 
4. Review and revise requirements with everyone in the team again at each demo stage

Make sure everyone on the team who is involved with the feature is 110% sure on how it works from end to end. Any grey areas will lead to ambiguous assumptions and that usually leads to confusion and maybe even failure. 

Will it work?

Sometimes you can only do so much to ensure a success of a system. You have established a good data contract. You mocked your services and tested some service calls from the server to client in a dev environment. When it is time to test with the real service, will it work? You don't know. Sometimes things happen and you need to deliver and can't push back on the delivery date. The team writing the other component slipped their deadline, you are now in a bad situation where you are essentially testing in the user acceptance phase. This sucks but all you can do is hope it works.

Should I unit test?

The biggest reason why unit tests don't exist is because of one of the following reasons:

• "I don't have time"
• "It is too hard to write a unit test for"
• "I'll do it after"

Umm, how will you know if your code will work? What will it display on the UI, what will it process on the server side? "Oh I pressed F5 in Visual Studio and it worked on my machine".  Fine that's sufficient if you are in school or straight out of university or you really don't know better (ignorance is bliss)

Automated "It works on my machine"

The time it takes to write a unit test to test an expected output is probably 5 minutes (create class, add test attributes on it, add test method, assert condition).  Now you have just automated the steps that you did to check the output on the UI. The beautiful part is that this is now automated and will always be tested. So now you are sure that it works. Two months down the road when someone changes the code not knowing about this text display and messes up your code that you worked hard on, they will be notified that it is broken. If you didn't write the unit test, you would have to manually check this test everytime! When another developer runs the code they will have to be aware of this feature and manually test it too.  It wastes everyone time and someone will miss it once or comment it out by accident. 

I don't know what I need to test

A lot of developers say this (mainly just junior ones). If I hear someone say this then I just reply what you trying to code. Most of the time they will say "Oh it should do this when this happens". Great!  That's all you need to know. Given, when, then aka behaviour driven development (BDD). If you structure your tests as given this scenario, when I do this, then this should be asserted, you can find yourself writing a lot more unit tests.

The audacity of hope

There was an article online stating why hope driven development is bad, Forget about Hope Driven Development (HDD), the cancer of software development. It is true that code quality and frequent demos are key to good software. That is the heart of agile development.

However sometimes we live in a less than perfect world. We may be put on projects where you are maintaining a code base written by 10 different people who have left the team.  You are now pressured by client demands to release a fix to the code base, whether that be a new column in the grid or some change to an interface. You make the change and now what? You release to a test environment and it works. You release to for QA and user sign off, great. Now you release it to production. Will your small change miss some corner case that is only possible in production that everyone couldn't test because you couldn't load that certain data into the database because another team was using it to test. You don't know. Are you gonna stop the release for this one small non show stopper bug? Here enters hope.