I was one of the founders of Workingmouse and started as the CTO. Over time the other founders moved on, one to property valuation, another to .net development/project management and the last became the CIO of one Australia's largest retail companies. I took over as managing director, but stayed involved in development and project management until the end.
Workingmouse' history can be considered as consisting of three broad periods, that don't necessarily have distinct boundaries, but serve to characterise some important aspects of the organisation at the time.
1. Central Control
Workingmouse was founded by four software professionals in January 2000 and incorporated the following month. The company grew rapidly to about 19 people, servicing one major client. The Tech wreck of 2000/01 greatly impacted us and so we went through the unpleasant task of letting most of the staff go and then living off our own personal savings/credit to be able to pay the few remaining people.
In those early days we operated in a fairly traditional manner for the time - waterfall style process, multi-tiered Java applications with specialists in each particular technical role, e.g. Java programmer, DB programmer, HTML/JavaScript programmer, system administrator. I was probably the only person technically across all roles.
We grappled with the usual issues of such a situation. How do we do fixed price, fixed scope work and
- make a profit
- have a happy customer
- have happy staff
- actually do a good job technically
2. People/Agile
Initially one of the other founders was highly focused on quality customer service, while I was driven to balance factors such as technical quality and work/life balance (as I had small children with a medical condition at the time). This dynamic, anchored by a developing mutual respect for one another drove radical changes in Workingmouse. Many things we did bucked the local trends of the time and I discovered just how dysfunctional the international software industry is.
The key changes that started brewing in 2001 were a shift from primarily procedural coding to OO domain modeling, waterfall to agile and an emphasis on hiring and empowering talented, passionate, innovative developers. While I describe these individually, they were very much intertwined chronologically.
N.B. this is intended to convey a historical perspective and I don't necessarily hold these opinions or discuss issues in these terms now.
I was driven to optimise our development speed by trying to work smarter rather than longer. When I discovered the idea of modeling the client's problem domain in an OO style, it appealed to me for several reasons.
- The prevailing multi-tiered architecture ideas of the time involved transforming essentially the same data structure between the implementations in each tier. This seemed like a gross waste of time and energy when a lightweight object model could act as a common data structure (and behaviour), utilised across the entire application.
- The object model could predominantly contain and enforce the various 'business rules' and 'validation rules', making them easier to locate and reducing duplication across the application.
- Objects could provide a more natural mapping between the code and the client's description of their world, thus making it easier for the developer to do the mental translations between them. The benefits being efficiency and less complexity and therefore hopefully less errors.
- Application errors could be reduced by composing small robust objects that ensure their interface doesn't provide a way to manipulate them into an invalid state.
The only Application Server that was remotely usable in development was JBoss. At the time I just couldn't believe how vendors could sell such rubbish and customers would actually spend tens of thousands of dollars buying it. Not only that, but they would then incur massive programmer costs trying to work with it. Running WebLogic in development was akin to applying a giant handbrake. We stuck with Resin until Tomcat eventually stablised enough to use it in production.
For some time both clients and Workingmouse had been facing the high cost of dealing with content changes in web sites/applications. We decided to solve this and build a Content Management System. This was our first (and only) product and we sold it as a service. While it was good, I believe it suffered from two business problems. Firstly the market wasn't ready and secondly we targeted the wrong segment (SME when we should have chosen enterprise). Consequently a decision was eventually made to retire it and focus our energies on services, which was profitable.
At some point I investigated the Spring framework and we originally adopted it to discard our own proprietary configuration libraries. It was only later on, when we moved to TDD, that we valued it as a Dependency Injection container. Back when we started with it though, heavyweight EJB and an App Server was "Best Practice". As far as I know we were the first doing Hibernate/Spring/POJO development in Brisbane and possibly in Australia.
Extreme Programming (XP) is the first agile methodology I explored deeply. It looked attractive as it attempted to address the issues we were experiencing.
- Clients don't really know what they want and programmers are terrible at estimating. Short cycle, iterative development with feedback attempts to address this.
- Clients change their mind regularly. XP attempts to positively support that rather than fight it.
- The genuine opportunity to do a good job. Traditionally, everyone pays lip service to quality, but when push comes to shove, other drivers usually take precedence.
- Emphasis on sustainability, of which maintaining a healthy work/life balance is important.
The name 'Agile' is a misnomer though. I think of sustainable business agility, but most developers think of freedom. Freedom from being held to estimates they couldn't realistically make in the first place or freedom to do a quality job (from their perspective) or freedom to work in a more social/group manner. Technical people try to spin business benefits on top of all this, often with a long-term outlook. However, because of their essentially self motivated position, they don't credibly understand the short vs long term business issues. Consequently hiring existing Agile professionals was sometimes challenging and naturally I don't fit into the orthodox Agile community particularly well.
From around 2003 when we started hiring again, we focused critically and selectively on finding the right people. We looked for technical talent, passion for improvement and honesty with the hope that we could provide an environment for such people to thrive. Sometimes we made mistakes and commercial realities did intrude, but other times I like to think we really got things right. In the Mythical Man Month, Fred Brooks writes of the massive difference in abilities between programmers. This is consistent with my observations of many people employed as programmers, both staff and clients. The differences in productivity and quality are surprisingly large.
When Ruby started emerging as a fashion, we like many Java developers that used TDD, wondered whether Ruby + TDD would be better. It was easy to dismiss the claim of 10x productivity gains, but while skeptical we undertook a few Rails projects. One of those projects was quite long running and exposed issues with reasoning about larger Ruby applications. Our interest in functional programming was emerging throughout this time and it easily eclipsed our interest in Ruby.
3. Functional
In 2006 I employed Tony Morris, who had previously worked for IBM on Tivoli and their JDK. Tony is one of the most intelligent people I know and he seriously challenged our ideas about software development. We thought we were critical and open minded but he took that to a whole new level and many passionate debates ensued. After some investigation into functional languages Tony and I began learning Haskell.
For some people this was a difficult time within the organisation. I was busy unlearning much of what I had built up, while those involved in ongoing projects didn't have the time to be involved in such a journey. I have always tried to be honest with staff and clients and so because of my fundamentally changing ideas I could no longer participate as easily in the general technical discussions. This situation brought about uncertainty as to the ongoing direction of the company.
In 2007 I decided that for all Haskell's elegance it was not going to be a viable option for enterprise software development services in Australia. Therefore we conceded on Scala as a compromise. It is far more expressive than Java, but still executes on the JVM and interoperates with existing Java code, making it far more commercially palatable. We completed our first Scala project in late 2007.
2008 saw Workingmouse in a position to confidently offer general Scala development and training services. Several more of our (highly capable) people had undertook learning Haskell and Scala. It was interesting to observe how difficult the transition can really be. It is relatively easy to learn the syntax of a new language, but much more difficult to fundamentally change the core abstractions one thinks and expresses ideas with.
After breaking the shackles of Java it is painful to go back to it. Workingmouse needed to find some Scala projects, but the global economic situation was deteriorating and so the clock was ticking. In general, technical management is very conservative here in Australia (that may deserve a blog post of its own) and so only one more Scala project was forthcoming. This was not sustainable and with financial markets crashing it was time for this services business to call it a day.
