During the past two weeks I built a system that is estimated at roughly 2 man months. No, I am not a coding monster, and I go lightly on the caffeinated beverages. I did that by explicitly stating that the code will have all the required features, but it will not be ready for production.

It is important to understand the difference between such an effort and demo driven or spike driven code. In both later cases, the main goal is to get something that works, without regard to maintainability or long term survivability of the code / effort. This means that you can take some very rough shortcuts along the way, to get there as fast as possible.

In this case, we have every intention of taking the same code base and getting it ready for production, but the overall structure and features must have been completed by that time. (This is a hard deadline constrained by yours truly availability, and cannot be budged.)

As such, I had to make the make compromises. They mostly dealt with error handling, validation and edge cases. That is, the thing works, and it has a solid foundation, but you are going to get... weird results if you try to do some things. Like trying to end before start, or generate a roster for the next 100 years.

This exercise got me thinking, do I really think that error handling, validation and edge case coverage are going to take 80% of the time?

That really depends of what you need for those, as a matter of fact, but that has consistently been my experience. Getting something to work tends to be fairly easy. Getting it to work right under attack is the hard bit. Getting it to fail correctly is ever harder.

In this case, I couldn't do any of those, so I made sure that when it failed, it would fail safely. That is a start, and we can build from there.

Another aspect that I have not touched is logging and auditing, which is critically important. If I need to debug to figure out what went wrong then I am in the wrong place without a map or a compass.