Working in a startup lets you face problems with strict boundaries due to the low budget/time/resources. You need to be creative to find efficient solutions. Part of the management of the available resources is done by development workflows.

With development workflow I mean the whole pipeline that brings a new release of an application (including the first milestone!). Obviously there is not a perfect development workflow, each project should adopt the one that fits its needs.

Setting up the strategy for Orbit, we've moved our focus on just two metrics:

• deployment time
• first deployment delay for new employees

The first metric is about the delay between when a change is done into the code and when it is available to the end users. Orbit is a desktop application, so the workflow is a bit more complex than the one necessary for a website. I'll follow this up on another post, because I think it is worth spending more time on it.

The second metric is maybe a bit understimated by other companies, instead I believe it is an aspect to study from the beginning, especially for a small company like SkiceLab. We have a small team, a good team but small. We also work on more than a single product, this means each one of us usually works on more than one codebase. Besides that we still care about all of our projects and we want to keep high the quality for all of them. Let's see how optimizing the second metric makes it possible.

A new employee that needs to touch the code has the following requirements:

• read the code
• make changes and try them
• have some kind of warning in case something is wrong in its changes

This can be achieved with good documentation, good source code, easy to install external dependencies (and possibily not many), a nice test suite.

A good source code has to be written with an uniform style, this make necessary to have coding style guidelines. Unconsistent patterns, non-uniform naming style and code duplicates don't help reading. I really like code reviews, they generally avoid stupid mistakes but most noteworthly they make programmers think their code will be read. The reviewer should also verify the code consistency.

Good code is also non redoundant and it's usually simple and compact. A good architecture keeps program components isolated. When I read a source code for the first time I need first to find where the logic of the main parts is distributed and I love to have an extremely low butterfly effect when I try to do any changes.

I've already written something about tests, still I want to remind it: it is important to have tests, it is even more important if these tests are mantained and extended during the development of the project.

Another important thing is reduce necessary resources: ideally an engineer wants to run the whole app on its own computer. If the app needs hard to install services, a nice way to avoid headache could be to distribute a VM.

There is something more I want to put the light on: working intensively in a project for several days let us gain familiarity with it. This "familiarity" won't last forever, try to stop working on it for few weeks and then go back reading the code again. The new employee is also the old one that moved temporarely to another project, that comes back from a vacation or that simply needs to switch between components of a large project. We are the new employee.