January 31, 2016 1 Comment
I was probably lucky having a great colleague who changed our installation/upgrade process into a single install.sh script. The script contained uuencoded ZIP as well, it unzipped the content (couple of Java EARs), checked the application server if all the resources are set up and then deployed these EARs. Having this experience probably around 2005 I got totally hooked to the whole idea of automation.
2005? Wasn’t it late already?
I don’t remember exactly, maybe it was even 2006. In any case, it wasn’t late for me. It was the next step in my personal development and I was able to fully embrace it. It may sound foolish, but we did not measure saved hours vs those we spent to get to this single command upgrade of our system. We didn’t have many other automation experiences. We had no integration server (not sure we knew what it was) and we struggled with automated testing. Even if we had wanted to measure we would have failed probably, because we simply were not there yet.
There is this idea of a maturity model – that when there are multiple levels of knowledge or understanding or skill or whatever, you simply can’t just learn the highest one, or even skip over any to get higher. Because without living the steps one by one there is no solid foundation for the next one. You don’t need formalized maturity model, very often there simply is one, call it natural progress.
Of course, I don’t mean to bring in a “maturity model” model to hold you back. Aim high, but definitely reinforce your foundations when you feel they don’t work. Not all models are prescribed, sometimes it’s more an exploration. But talking about build automation, you can find some maturity models for it too. (Funny enough, it mentions Vagrant/Packer on the top of the pyramid, because these two tools and last two weeks with them made me write this post. :-))
Personal and team maturity
We were a small team, far from the best in the business, but we were quite far ahead in our neighbourhood. We were following trends, not blindly, but there was no approval process to stop us trying out interesting thing. By 2010 we had had our integration server (continuous build), managed to write automated tests for newly developed features and even created some for critical older parts.
Then I changed my job and went to kind of established software house and I was shocked how desperate the state of automation was there. Some bosses thought we have something like integration server, but nobody really knew about one. What?! And of course, testing takes time, especially automated, and so on and so forth… There was no way how I could just push them. I gave some talks about it, some people were on the same page, some tried to catch up.
We got Jenkins/Sonar up and running, but automated testing were lagging behind. We had really important system that should have had some – but there were none. People tried, but failed. But they did not pursue the goal, they saw only the problems (it takes time and adds code you have to maintain) but did not see the benefits. There are cases when doing more of the wrong thing does not make it any better (“let’s do even more detailed specification, so that coding can be done by cheaper people”), but there are other cases when doing the right things the wrong way requires different approach. It requires learning (reading, courses) and practice. There is no magic that will get you from zero to fourth maturity level in any discipline.
You can have mature individuals, but the team (or division, or even company) can still be immature in what you pursue. And it strongly depends on the company culture how it turns out. Other way around is much easier – coming into more matured team means you can quickly get up and running on the level, although it is still important to catch up with those foundations, unless you want to do what you do just superficially. This may be acceptable for some areas, it may even be really efficient as not everybody can know everything in all the depth.
Proof vs belief
I really believe, I got lucky to get hooked. You can throw books at them, you can argue and show them success stories. Just as with anything that is based on “levels of maturity” you can’t simply show them the result. They don’t see it with your eyes. It never “just works” and there are many agile/lean failures showing it – mostly based on following the practices only, forgetting values and principles (which is an analogy of a maturity model too).
I got my share of evidence, I saw the shell script allowing us those “one-click” updates. But for some this would not be enough. I was always inclined to learning and self-improvement. Sure there are days when I feel I do the repetitive work “manually”, I guess it’s because I was out of mental fuel. But in most cases I was trying to “program” my problems.
I rather messed around with vim macros for a while, even if it didn’t pay off the moment I needed to change 20 lines. Next time when I needed to tweak 2000 lines, I was ready. I never thought about kata, but now I know that was what I was doing. I was absolutely sure about why I do it. I didn’t see the lost time, what I imagined was my neurons bending around the problem first, just to bend later around the whole class of problems, around the pattern. I didn’t care about proof, I believed.
I see the proof now, some 15 years down the path. I see where believing got me and where many other programmers are stuck. I see how easily now I write a test that would be mind-blowing mission impossible just a couple of years ago. And I know that the path ahead is a long one still. I’m definitely much closer to the top of the trends than anytime before.
I don’t think it was that install.sh script alone that brought the power of automation to my attention. I believe it was one of defining moments, my favourite one when I try to convince people with a personal story. It saves us incredible time. It was kind of documentation, the best one, because it was actually running. I would understand a lot of this much later and it’s crystal clear to me now.
But it was belief in the first place. That made it easier for me. When I met a culture that didn’t support these ideas (at least not in practice) I was already strong enough to do it my way anyway. And I saw it was paying off over and over and over again. While my colleagues declared “no time for testing”, I was in fact saving time with testing. People are so busy to write lines of code, maybe if they thought more or started with a test they would get to the result faster – with the benefit of higher quality packed in too.
How can we hope for continuous integration when we don’t start small with tests and other scripted tools? There are so many automation tools out there and the concepts are well understood already that staying stuck in 2000’s is just pure laziness. The bad kind of it. Doesn’t matter if it’s a single person or the whole company.