Every business these days is working in a fast moving, disrupted, technology-driven world. In order to survive we need to be constantly thinking outside the box, and potentially contrary to the ways we've been working for years.
For the last 10+ years I've primarily been a C# / .NET developer. This ecosystem is great, there are thousands of great packages available. The one thing that's been irritating me of late is the challenge of running .NET in containers such as Docker.
As luck would have it, I recently got an opportunity to work on a new side project FairDealFx which I (perhaps stupidly) decided to do using the MEAN stack (MongoDb, ExpressJs, Angular and Node). I've done some javascript and typescript as part of web projects in the past, but not an entire application stack.
This undertaking began as an offer to help a friend out with a project he had been working on in his spare time. His prototype was working well but I didn't think it would scale too well, so I offered to help refactor it a bit. This is when I got entirely carried away and picked a whole new tech stack.
Our first "Hackathon", TattsHack, is done and dusted, and what an experience. From the original idea through to the event it was only a few short weeks, and of that we were only actively working on it for 15 business days.
In that time we went from a blank canvas to forming teams of volunteers to look after communications, rules, facilities and most importantly food! We designed logos, stickers, posters and had t-shirts printed. Given that it was the first event of this type it was decided to keep it to an MVP (Minimum Viable Product)... I think we failed there - it wasn't minimal by any stretch of the imagination. Even though all our volunteers and participants had their normal workloads to take care of, they threw themselves at the task with an enthusiasm that is rare to see. It was a clear sign that the tide of cultural change really is happening at Tatts.
I'm using the ServerSpec framework to do environment validation of development and test environments. The first version is set up in a very basic way where you pass a single host IP or Name and it connects over WinRM.
This is specifically designed to be an example of how one might test long-lived environments without taking the leap into configuration management tools such as Chef. Although that would be the logical and ideal situation, there are times where it's not yet possible to take that step.
For the second part of this series I'm going to take a bit of a detour away from the code. One of the things I'm seeing a lot of recently is projects where a huge amount of work is going into shippable features, but not actually shipping anything until the end. Of course you can't ship a 1/2 done product, but you could start shipping a minimum viable product and just because you're "an enterprise" doesn't mean you can't get value from Lean development methodologies.
One of the biggest time-killers in software development is deployments (and environment management). I've worked on some big projects recently where people are spending many hours each week creating, maintaining and deploying software packages. These hours could be better spent fixing bugs, or adding value to business by adding features to the software. Instead, they're spent manually performing and tweaking installations of the software, often with additional overhead due to the inherent human errors along the way.
Gathering useful instrumentation about running applications such as throughput and performance can be tricky, but invaluable for understanding bottlenecks or latency problems. There are a number of commercial products that cover this area such as AppDynamics, AppInsights, New Relic, Stackify etc... I've had some experience with these tools (especially AppDynamics) and I would say if you're going to be supporting an application in production where there would be financial impacts if your application is performing badly or fails in production, then spend the money on one of these tools.
Following on from my previous post about logging this one will go a bit deeper into the logging story. There's a fine line between too much and too little when it comes to logging. On the one hand you don't want to skip logging something that might make it easier to diagnose a problem later one and on the other hand you don't want to create so many verbose log entries that you just can't find the information you need.
If there was going to be a "silver bullet" that will make your applications more supportable I think I would suggest that appropriate logging would be it. There are obviously a lot of other things you can do to make applications easier to support, monitor, debug and develop - but without logging you're shooting yourself in the foot before you even start.
