Golden Age of Development
A year after I graduated college I was working for a team at Caterpillar that was writing the Windows service tool for all of their equipment. It was written in MFC C++ and was enormous. I don’t remember how big it was, but it had thousands of files in multiple projects to compile down to machine code. There were times that I’d be in the middle of a hectic day and would be overjoyed when I did a sync and see that STDAFX.h or CONST.h was updated. Why? Because this meant I had something like 30-40 minutes to do whatever I wanted to do. I wasn’t going to be writing code, because those two files (and a couple others) meant a COMPLETE rebuild. It was time to go grab a coke, take a walk outside, see what my friend on the other side of the building was doing and then still get back to my desk with 15 minutes to read random websites.
Of course, there were times that I absolutely HATED to see either of those files come across the download. I was 2 minutes away from fixing a bug and another developer told me that if I used his method I’d be done. Do a pull and see STDAFX.h come across? Guess I’ll sit here for the next 30 minutes hoping it builds faster so that I can check in my change and go home. Even then, I’d push my changes and wouldn’t know for sure that I got ALL my changes until the next developer pulled and either did or did not get build errors.
At one point the builds were so painfully slow that we looked at buying 3rd party software that would steal extra CPU cycles from everyone on the team to help build on your machine. It turned out to not be worth it. In the end, a redesign of the back-end cut build time to 15-20 minutes, which at the time was a miracle.
Thing was, that was just a normal build of the EXE. Once that was done there was still a lot of work to be done to get an installer package. Thankfully, we had someone take care of that on a regular basis, but just pulling, building and creating an MSI took a few hours. Before I started, it was an all-day event, but they were able to automate it right before I got there.
Fast forward a decade (actually, a bit more) and things are drastically different. It dawned on me this weekend as I worked on two separate projects. One personal and one work project. My personal project is an app I wrote about 6 months ago to track how much time I
waste on spend doing Brazilian Jiu Jitsu. It’s nothing fancy, and you can check it out over at my BJJ blog. The app itself is open source and the repo is on GitHub. It uses a mongo DB back end and Facebook authentication. It was after making a change to this app on Friday and publishing that I started to realize how awesome technology was. I was able to use a free source code system (Github) and a free version of hosted MongoDb (Mongolab.) I then “Web Published” from Visual Studio to my hosting provider and my updates were live. The site knows nothing about your passwords or email address. It simply believes Facebook when it says you are who you are, and it stores your data.
That was pretty cool. But the icing on the cake came later.
At my day job we’ve been busting out some neat tools for our internal use. One of them is a project dashboard that we’ll use internally to keep track of the stage of projects, as well as important links (alpha sites, wikis, repos etc.) The public version of the same site will be used a portfolio of sorts. The app itself was largely written last week, but it needed some serious styling. That got done Thursday afternoon. After the styling was done the site was slow, so while I was off Monday I took a few minutes to look at it. (I didn’t have to, nobody would have minded if I waited until today to look at it, but I wanted to play around.) I found the bottle neck and pushed to Github. That’s where the real fun started.
I was at home on my personal laptop and pushed to our Github account. This saved all of my code, as well as triggered a Team City build. This not only built my app and ran all my tests, but it deployed it out to our alpha sites for me. Our alpha sites are locked down to users in our domain via Google auth. In a matter of minutes (literally 1:27) the code I just wrote at home was up on our alpha site ready to be viewed. I had a reasonable certainty that it would work because tests passed. I was also fairly confident that YOU couldn’t see it, because you’re not on our Google account. I didn’t have to log in to a VPN to push code, see the build status, or check the actual site.
So that was pretty cool, that less than 2 minutes after I did a commit I had something on alpha. But like Billy Mays would say, “That’s not all!” Today when I got in, I logged on to our TeamCity server (There was no technical reason I didn’t do this from home, just felt like stopping when I did.) I created a Production Build template (probably took 5 minutes.) Then from that template I created a new build for the site I was working on. I then created a Prod branch on Github, and again, in under 2 minutes I had my production site going.
I can now go from code change to live site in under 2-3 minutes, running a complete suite of tests and deploying. Ten years ago (even 5+ years ago, when I left Cat) I couldn’t go from code change to production ready application in under an hour. The tools we have today make right now the golden age of development, and it only looks to get better.
In fact, I saved so much time, I was able to write this blog post today (Hi Billy!)