Polyglot

Build Valuable Systems, Better and Faster

Advanced Development and Delivery (ADD)

I have been paid to develop and deliver software since about 1980. That is 35 years of professional experience. When I started in 1980 there were a lot of ‘old timers’ who had been around since 1965 or so. They were 15 years ahead of me, and even after finishing college, I had less than ten years to their twenty or so. This was both intimidating but also very helpful: after college my main programming language was Smalltalk (ParcPlace, Digitalk, etc.), which included full source to everything. So the ‘masters’ would write masterpieces of code, and I would read them. And then try to write my own beautiful things leveraging the masterpieces. I was late to the party, but could learn quickly.

I also have one other unusual advantage: I do startups. Lots of startups (http://SlumsOfPaloAlto.com/). A total of ten software startups over a period of a bit more than a decade. Each of these startups failed for one reason or another, but each one enormously progressed in how well my development team ran. Eight, nine, and ten were crazy productive: I would run production servers for the whole company at the same time that I built out the product. Alone. And generally way faster than the product management team could keep up. At PeerCase the product team actually asked me to slow down delivery so they could ponder what they wanted for longer. I literally went to Disney World during ASH (a medical conference) to prevent myself from releasing new features I knew they wanted. I was paid to not work (well, I was contracting at the time, so I stopped the hourly billing clock, but my project bonus was the same).

10x Productivity

Besides doing startups, I also consult for companies. I try to help them improve their development methods, usually by at least 4x if not 10x. A lot of times, people don’t believe you can improve things to ‘10x’ the productivity of the current team using new development and delivery techniques. At one company, the CIO and a number of other executives believed me, but I had to convince a lot more stakeholders. So two amigos and I sent me into the trenches. I started taking projects estimated as two-developers, six-months, and doing them in one month. Part time. That is more than 12x productivity. Realistically it was likely about 20x the productivity because the teams tend to miss their estimates (they go over).

Then for fun, I was sent into the trenches again but this time had to use some of their development methods. Still way faster, but back down to 10x or a bit better. As the trenches became “less mine” and “more theirs” I would slow down more and more. Eventually everyone tired of each other and the experiments stopped.

Bizarrely, this company that saw the 20x… continues to use the slow, unreliable, method of development. The workers may have been scared that the company would only need one in ten of them if they changed to a better method.

Development Stagnation

Again, I have been doing this for 35 years. My skill as a developer has improved over that time, and I now view myself as an ‘8’ where each increase from ‘0’ represents a doubling of business productivity. So I am 256 times as productive as a ‘0’, and 16 times as productive as a ‘4’. Stephen Wolfram, Bill Joy, and others are above me, but there are not a lot of people up there anymore.

Getting to be a ‘4’ involves understanding how to program. Getting to a ‘6’ involves understanding business needs. But getting to an ‘8’ involved an incredible / revolutionary change to how software is developed and delivered. For most of my career, getting to an ‘8’ was not possible. Or at least the scale had to be different (i.e. add 50% for each number vs. doubling).

The problem was that software development had made absolutely no progress for 40+ years. “You lie!” people claim. “We build software very differently then we used to!” they say. Yes, some people have made progress. But it was people doing it wrong for 40+ years. The people who did it right (Xerox PARC, MIT’s Lisp group, Xerox El Segundo, Tektronics, etc.) were buzzing along happily with a 4-10x speed advantage over the rest of the industry.

What is this amazing way to build software? Well, for 40+ years, the best way to write software was to take a working computer and tweak it. Then clone that. Voila: you have a new capability on all your computers. Testing is trivial. Demoing is trivial. Fixing is trivial. Tweak. Clone. Repeat. Smalltalk, Lisp Machines, Xerox Stars, and so on all used this model. And they were blazingly fast to develop on. And to learn how to develop on.

If you wrote software any way different from that, you were just punishing yourself. Your software would regress because you touched too much and broke things. Your software would take too long to write and be buggy because you wrote it from scratch instead of tweaking something that worked. Your software would not do what the business wanted because you spent months writing it instead of hours tweaking something that was close. Pain… pain… pain…

When I shifted to Java, I dropped to a ‘6’ from an ‘8’ in Smalltalk. Lots of developers hated leaving Smalltalk because of that. But in my case, I cared about the libraries and people who were moving into Java. It was not a great language, but it had a lot of potential. And Smalltalk imploded when Java was released for free.

Automated Testing

So I am in this crappy new language, dealing with jars/libraries (usually without source), deploying to containers, building out linux servers in data centers, and trying to make this whole thing scale to millions of users and international development teams who like to break my code. It was fun and hell at the same time. To avoid my going down to a ‘4’ because other people broke my code, I leveraged XP practices that were entrenched in startup #3 (Evant / Retail Aspect). This was one of the first full-bore XP companies with Kent Beck and Rob Mee at the helm of the development team.

XP is very much oriented to “Write tests first”. That is stupid. You need to figure out what you are doing and writing tests is not a good way to figure out how to do something. You do it to figure out how to do it. But after you do it, you should write tests to make sure the code still does it tomorrow. Unfortunately, people usually forget to write tests after, hence the XP maxim. I lucked out and a whole bunch of tests existed when I showed up to help save Evant. I needed to scale the product to be bigger and faster. On the order of a million times bigger data set and a thousands times faster execution. But it should still work, and if it did work it would not fail any existing test (unless we changed functionality).

That sold me on automated testing. It made me slower (say a ‘5’) but it protected me from other people breaking my working code. Eventually we used Excel for the automated tests, the business people wrote them directly, and I was back to a ‘6’.

Grails and Opinionated Frameworks

I became an ‘8’ again when I started using http://grails.org/. The language (Groovy and Annotated Java) was now approaching Smalltalk if a bit uglier. And the automated binding to the database, plugin model, and other great features in Grails made it so I simply didn’t have to worry about a lot of stuff. I was getting different benefits from Smalltalk, but they netted out. And I had the same benefit as Smalltalk in onboarding others: (1) This is the Grails way, (2) These are my ‘tweaks’ to the Grails way… now start asking for features and go build them.

Flex and Angular

On the client side, I had shifted to using Flex very early on for a company called Winster. It was a bit bleeding edge at the time, but Flex was very powerful and very productive. It was basically Smalltalk on the client. Eventually Flex/Flash became non-viable because of the iPhone issue, but then Angular jumped in to replace it. I tried others (e.g. YUI, Sencha, etc.) and they have pros-and-cons, but Angular is very good and very Flex-like.

Advanced Development and Delivery (ADD)

OK, so above describes a lot of the stack I tend to use, but that isn’t where the ‘256x’ comes from. Above I claimed I was an ‘8’ but that was on the old ‘50%’ or maybe ‘70%’ more scale. On the new scale, I am a ‘6’ with the stack above until you add in the ADD: The Advanced Development and Delivery environment.

The ADD came to me incrementally from Evant, through my own failed attempt at productizing it (Velidom), and fully germinated with my last software startup: Rumble. “Amusingly”, Velidom was killed by two of the four ingredients, tried to work around problems with SVN that is replaced by one of the four ingredients, and included as part of the product one of the four ingredients. If we had just focused on that one ingredient and not the whole software factory, Velidom would now be owned by Atlassian.

The four ingredients are:

These four ingredients, when baked properly together, give individuals and teams 4x or more productivity. No, you can not substitute the ingredients. Not until you understand what they are and how they work together. Yes, I can substitute ingredients for the above, but the above are the current gold standard. And hosting your own version of any of these products is also a ‘substitution’ and not equivalent to using them as a service.

Four Ingredients, Three Roles

For more details or questions, please contact me.

Comments