You’ve asked how this is all possible

Critics would be right: we wouldn’t be able to deliver so ambitious projects within such small team. After all many of our competitors are behind on feature and design fronts and still employ teams that are few to several times larger. So how do we keep on winning time races with a team of just two to three engineers and designers?

Because growing numbers always eventually makes you slower, no matter how you split the teams. This is different than to what many competitors do and sets us aside in terms of productivity. We wouldn’t be able to turn around features and improvements if we were forced or pleased to pour ever more people at ever growing complexity.

Whether we could or not, we focus instead on the rate of change as in many areas we really lead the innovation edge. For instance, for those who are interested in project management tools, know that with TaskBeat we were first to deliver a fully integrated project-tasklist-timesheet-budget management that our competitors subsequently copied, have tried or still try to copy.

We compensate small size of team with extra productivity. We do that by automatically generating code. We were only able to deliver so quickly and keep on winning time trials against our competitors because of the automation. Automating code means: building and optimising source code by machines instead of creating sets of files that dozens of engineers hand craft.

Therefore we focus solely on technologies that are ultra productive in terms of what we do. We weigh each decision by maintainability of our products. We never take anything onboard just because it solves one or two problems. Technologies that might be awesome, interesting or powerful are not even in our field of vision, if they’re just tools and not factories.

Automatically generated code sometimes might look ugly to whoever expects more than design and functionality. After all, application generators only care about spitting out lines that can be executed by either large number of different machines, or to be optimised for a particular type of machine, but never optimised to be taken apart and inspected by humans.

The benefits of producing code automatically instead of manufacturing it are huge. If you do your homework with application generators you can make sure the product is nothing like automatically generated, yet its maintainability is huge. After all if you want to change stuff you only change how it’s generated, and need not to focus on re-factoring of all of the code in each of your classes or projects.

Interestingly with code generators you can keep on climbing on the ladder of abstraction further and further up. Watching the watchers: generalising your code production process on an ever higher level guarantees consistency of how it’s applied not only in different parts of your project but different parts of different projects, and even different products.

Let’s talk examples here: a single line of change a developer makes to the code generator at a very high level trickles down right now to hundreds of changes in classes, several projects and even both: SpendingTracker and TaskBeat – two different products simultaneously! We’re talking a single reconfiguration – the amount of work roughly equivalent to a four person’s coding in a week’s time.

One can tell a developer who cares from another by the quality of their code. Many still often mistake the process of things being hand-crafted with quality of end products. It’s like in the old days: people cared about the process of putting individual stitches in your pair of shoes over their price, durability and speed to market of a pair of sneakers that are assembled by machines today.

Where others hand craft script files and tailor style sheets, there are many areas in both SpendingTracker and TaskBeat where developers don’t have to care about generating individual scripts or styles at all. Instead they define test cases and sets of rules of how the code needs to be generated and the production of scripts, projects and styles is being taken care of for them.

This is the very business we specialise in: automating code production process. Where others take pride in hand making their handbags: hand crafting their javascripts and stylesheets and putting a human touch to each and every file, we focus entirely on automation: focusing on the factory process, not the manufacturing of each stitch…

In case of our products we care about: distribution, convenience, design and durability, never about: polishing each item with a different brush individually. We leave the individual gluing, stitching and packaging to machines, instead taking pride in how many lines of products can we deliver having just one factory manager pressing very few buttons.