Automate everything

I'm a huge fan of automation. I don't like repeating things and I don't like doing everything manually. Everything can be automated - code generation, deployments and migrations. You can script how your application is being built, how it is being packed and how to notify everyone interested in this fact. After few months of work it saves even days of your priceless time. You can hardly believe in that? Let's see(all below examples are real functionalities prepared for my side-project):

  • Using command line to generate modules or features in your application

Most applications are based on very simple CRUD modules, which allow users to manage the data. No one likes to write such code - just query the database, do some validation, return a success or an error. Such modules or features, developed by many devs, tend to evolve into some kind of "an-app-inside-an-app" - everyone uses different conventions, code is formatted differently, the very same functionalities are structured using different patterns. Even when you are creating an application on your own, you sometimes change your style and approach. To get rid of this problem I've created a simple command line tool, which creates whole feature structure using only given feature name(of course it generates both handlers for API and AngularJS controllers and factories). I think, it saves me about one hour of writing the same code all over again per each feature. I have around 20 features so far.

  • Generating AngularJS factories based on requests data using Fody

It's a similar feature to previous one but it extends it rather than overrides it. When I have my structure created, it is obvious, that in some point in the future, I will have to add something new to my features. Because requests, which are a part of my API, are also used by factories in AngularJS(at least in terms of URL structure/HTTP verb), I don't want to change something in my JS code each time server-side code changes. That's why I'm using Fody(or Mono.Cecil if you wish) to generate this kind of client-side code.

  • Notifying users about new deployment/delivery using EventStore

I wanted to notify each user about the fact, that a new version of the application has been delivered. Because I extensively use TeamCity and psake, I decided, that my build script should just send an event to EventStore, which will be processed and respective action will be taken. I don't think about it, it just happens.

  •  Packing and deploying application using TeamCity + psake

Although I haven't got Octopus yet, I really wanted to pack and deploy my application automatically. It's the biggest problem for most companies - automate your deployment/delivery process so human factor is minimized. I decided, that everything necessary can be zipped by psake and just deployed to the destination server. Because psake is basically PowerShell, I was able to shut down the old version of my application, deploy new version and start it much faster, than doing it manually. No mistake is possible.

  • Creating issues in YouTrack automatically when not handled exception occurs

This is something unusual, but I realized that it's a real pain in the ass. Working with your client can be difficult sometimes, especially when you're trying to get some details about error he or she mentioned. Yes, you have logs and some general idea what was the flow but sometimes, you need a whole context. You can implement audit of each operation performed in you application(and this is not a bad idea). I decided to do something more interesting from my point of view - to automatically report an issue in my YouTrack when a HTTP 500 error occurs. It saves my time, it saves my client's time and that makes him happy.

Personally I think, that automating things - in development, in your process, in management - is a great opportunity to try and test your ideas. Initially you have to invest some time in making all those things, but after few months, when you just write

--create -featureName=Foo

instead of writing boilerplate code again and again, you will now it was worth it.

The curse of the babble

We talk. We, as developers, software engineers - whatever you call us - we talk. We talk about implementation details, we talk about our toolset, we talk about performance issues. This this a part of our job - if you don't talk about your code, ideas or problems - you have a problem. To be honest, people are just designed like that - you can talk before you can write. However, there is a one specific "talk", which I believe is a curse and hits whole IT really hard.

Have you ever tried to introduce a new tool for your team? It can be a build server, a source control system or a new library. In most cases it is pretty easy - someone gives an idea, you discuss it, point possible problems. Maybe someone is more experienced with this tool and can decide whether it is a go/no-go. Mostly it is a moderate(or not - you know, each dev knows better) discussion and you can close it within an hour, no strings attached. You know why such discussions are the most definite ones? Because devs know the best, what they expect from a tool and what it can give a team.

On the other hand it is not always true, that a team decides. This is especially true for big companies, which involve tons of bureaucracy. You cannot decide on your own - you have to ask your manager, your architect and your director. There are some DevOps engineers and middleware specialists also. Don't forget to ask your mom, your wife and your dog. You have to ask everybody because everybody knows what you need better than you.

Have you mentioned everyone in your email requests? Good, now let them meet and talk. Let them babble, let them discuss all those things they hardly understand. Just imagine:

  • Dev: Hi All, we need a TeamCity instance accessible for us so we can test our .NET apps build process.
  • Mgr: Hi Joe Director, my team wants a TeamCity server so they can work with it.
  • Joe Director: Architect, don't we have such thing in our infrastructure?
  • Architect: No, we have Hudson only - they should be OK with it. Do they want a whole server? They have to ask our server team.
  • Dog: Bark, bark!
  • Dev: I said we want only a TeamCity instance + we want to build .NET apps...
  • Mom: Your grandpa gave a TeamCity your grandma instead of a wedding ring, I will try to find it...
  • Finance: It costs 1,999.00, we can't afford it this year.
  • Joe Director: What?! I have to pay  2000 for this Hudson server?
  • Wife: Are you getting  2000 extra this month? I'll go shopping, wow!
  • Dog: Bark, bark!
  • Mgr: Why do we want to test build process anyway? Can't you just use MSBuild?
  • Dev: We want to test the 'whole' process and by the way - TC is free!
  • Architect: Is it free? Is it enterprise enough? What about integration? Last year we bought enterprise ESB solution for $100K and since we haven't started to implement it yet, I have to know whether this SimCity will work with it.
  • Finance: SimCity? Can we also get it?
  • Dog: Bark, bark!

Sounds familiar? I think everyone knows that feeling.

They will talk for a month considering whether a tool you mentioned is needed for you. They will spend their time discussing, arguing and trying to prove, that they can or cannot afford it. They don't care, that they will spend money while talking. They will spend much more that your tool costs. Funny fact that they don't seem to care about it.