One tool or set of tools that software developers didn’t know we needed in the 70’s are those for doing software “builds.” For the not-so-technical of the readers, I’ll give an informal definition and write that “a build” of software is functioning software. As a verb, “to build” the software is to create a new build. These are typically numbered sequentially: Build 1, Build 2, Build 3, …
A build is like a version of the software, but unlike a version, it might not be ready for prime time. It might not have all of the features needed for a user to do much of anything useful, but it is actual software that does something.
One goal early in starting to write code is to get to a first build. We had planned to use whatever tools were delivered with the database plus open source tools to create our build processes. After we looked at Cache’, with its proprietary storage of source code, we were presented with an offer from a third party software provider that we decided to take. Using George James for version control and builds has proven to be a good decision so far.
One catch is that the build process is not fully automated. It requires someone to press more than one button when it is time to create a new build. I have no doubt that in the future we can figure out how to automate this process more fully, but for now I am doing the builds. They take me about 1/2 hour each to do, prior to any regression testing, which is also not automated. So we are not doing daily builds, but we are not getting software written each day either. Weekly builds or build-on-demand is working fine for us right now. The version control software went in easily, thanks to work by the vendor and Ken to get it set up. Very soon after installing it, we were able to make that coveted first build.
So we are past that milestone. We are up to build 18. At what build number will we have software we are ready to deploy for the first pilot test in a “live” environment? Oh, maybe we could take bets on that one. I’ll toss out an estimate based on nothing except my more than 30 years in the industry and the past year getting this project off the ground with requirements, design, foundations, and going through some of the learning curve coding with the selected tools for the target environment.
Let’s see, one build per week, 500 builds to go, that’s 500 weeks or just under ten years. Nope, better guess again. When the estimate does not match what we desire, we come up with another estimate, right? I’m thinking I need to speed things up so that my own ballpark estimate is in the ballpark.
To speed things up, we can add more resources, whether people or money. Money can even attract people, or so I have been told. I plan to do some work to pursue some funding this year. Having funding can reduce the time to delivery, while pursuing funding will extend it during that time. That is just one dilemma regarding funding.
We can also change the scope to reduce the timing. There is a philosophy in the software development industry of deploying software that is “good enough.” While I understand there are business trade-offs, I want to deploy when the software is “great.” OK, so make that Build 718? Rats, the reason to write this paragraph was to try to talk myself into a smaller scope and I talked about quality instead of scope. Maybe that is because when writing software to be marketed, when you do not have a captive customer, it is important to recognize that scope is part of what the prospective customer perceives as quality.
Another way to improve the timing is to swap out slow developers for fast ones. I heard long ago that the difference in speed between a fast and a slow developer was a factor of ten. Once upon a time, I was fast. I’m going to blow my own horn with a story, because otherwise based on my experience this past year, if you continue to read this blog, you just might not believe that I was ever a good, fast developer.
OK, here it goes. They did this experiment with me, without my knowledge. In the early 80’s, I wrote a report (printed on greenbar, of course) from a verbal specification in 3 hours, skipping lunch because they said it was important. Apparently when I was getting the verbal instructions from the boss, my colleague was getting a written specification from our lead system’s analyst. He was also told to put everything else aside because of the importance of this report. Three weeks later he delivered his report, which they compared to mine and the two reports did not match. His numbers were wrong. They decided that 15 days for inaccurate software compared to 3 hours for accurate software was not good enough. Maybe they also didn’t like him sitting in his office with his feet on the desk reading the Wall Street Journal when it came each day. They fired him.
The most promising approach to speeding things up without dollars is for the team to become more productive. We have had bursts of activity, but have ground to a halt at times, with periods where no one is coding, or where only I am writing any software. Remember, they all have other jobs, ones that pay.
We have a build process and we have builds. We need the process of putting new software into those builds to be better. The development team needs to hit a stride, work with good procedures (I favor scrum-like approaches, but have not really pulled that off well enough), and be a highly productive development team. I have not always been good at helping to remove the obstacles keeping others from being productive, with the learning curve being tops among those.
I am hopeful that each of the other developers on the team will also work to get their individual motivation and processes in shape, along with those of the team as a whole, so they enjoy coming along with me, doing something each week to move the software forward. I was thinking that if I were to build it, then they would come.