Developer perspective: differences between startup and consulting business

How I got into a startup

Five weeks ago, I started working in a startup called At first I didn’t even think I would like to join a startup as the whole 5 years of professional coding I had always worked in a consulting company. Then I saw an ad on Facebook of Smartly Fast Track and got into lunch with Smartly employee after solving it. After a couple of lunches with different people at Smartly, I was pretty convinced that this company would be a great place to work.

Before joining Smartly, I was working in different Finnish consultancy companies for the last five years, helping clients succeed in their software projects. Depending on which client I was working for, sometimes I got to work with interesting technical problems e.g. indoor wifi location tracker software, and sometimes the projects were not so interesting. Part of the consulting business is that you don’t always get to decide what you want to do, but instead you do what the customer pays you for. Usually customer pays by hour so you need to have bookkeeping in place where you write what you did and how long it took. Bookkeeping doesn’t sound very bad at first but depending how much detail the customer wants of it, that may mean that you spend 30min each week to have proper bookkeeping in place. That’s two hours per month, which suddenly sounds a lot! At Smartly we have nothing of this as you are not required to have hour book keeping but instead you have to take care of the hours yourself so you are not working too much.

As a consultant you don’t own the software (usually) you write, but, on the other hand, you’re not the one who carries the possible legacy either (unless you spesifically are paid to fix a legacy software). On startups, you are the one who will carry the legacy and work with it or improve it. This is a good opportunity to learn and see how software evolves over time. One of my personal interests is be part of software project for several years, so I could see how the software changes and also learn deeper topics about the technologies used. That was something I tried to achieve as a consultant as well but as a consultant you don’t get to say if customer keeps buying your services or not. This happened to me more than once, and as I was a consultant I switched projects almost every 6 months. So in the consulting world you may need to jump from project to project pretty regularly. That doesn’t necessarily be a bad thing if you prefer to do quick projects, but as a side note, it may be slower to deepen your technical skills as a consultant than joining a startup. If you value learning and want to learn a lot and fast, then startup may be your thing.

The code

There was a lot of code produced during the first three years of Smartly, and not all of that code was beautiful. Especially in the early stages of startups, legacy code is almost certain to exist because of super limited time. You don’t choose the latest reactive UI libraries or the pure functional backend technologies if those are not already familiar to you. Instead, you choose the tools you know you can get the job done with and do it. What you built is what you have to live with. You cannot escape the legacy but instead you have to make it right. As a consultant you may have the option to flee if you don’t feel like that you want to do that kind stuff. If code or development process look too bad you always have an option to say “we cannot help you”. In a startup, you don’t have this choice. If you built it, you fix it. Personally I think this is one of the things you can learn the most when working at a startup.

At Smartly, we have pretty complex backend which is hard to unit test because the architecture has evolved so that not a lot of unit tests have been written during the time of the development. Instead of trying to change it so that it would be easier to write the unit tests, the team decided to build extensive set of api tests for a safety net. What our backend does (among things) is that it communicates with Facebook API so it makes sense that we test things what goes out of our application and what comes in. Those API tests are a good way to deal with testing our backend, but we still lack an easy way to write even more and better tests. The easier the test writing is, the more tests there will be. This is one the reasons why we’re planning on rewriting some of our application logic; so we can create better architecture and build even more scalable and robust system. When you join a startup you get to decide how to solve the problems and you also carry the responsibility. Sometimes you get to do this as a consultant as well but sometimes the customer tells you (if they are technically capable) how they want the problems to be solved.

The process

We have a couple of feature teams with two to five developers per team. These teams have a kanban-like board where they track their daily work. We also use electronic ticket tracking for stories so we can provide an overview for anyone who is interested in following the bigger picture. The idea is that developers get to say what they want to work on. Feature teams are not silos and they are not sealed. People inside teams can change depending on what needs to be done and what people want to do. Some features are prioritized over others, so there must be people working on them, but otherwise people can choose what they want to learn and do.

This is really nice, since usually if you work for a client, there is a fixed set of tasks that the client wants to be done. You may suggest what you want to do, but depending on the client, that may or may not happen. At Smartly, we have a lot of things that needs to be done and, as a developer, you can choose what you want to learn and then do it. You don’t need to ask for permission from the client to do something, you just do it. You may need to ask for forgiveness afterwards if things didn’t play out well, but you and your team have learned so much in the process!

I was already pretty familiar with Scrum and Kanban techniques before joining Smartly because as a consultant it was very common to work with those topics. Usually the case was that the customer’s software development process was not good enough so it needed attention especially at the beginning of the project. When I joined Smartly I was surprised that how good things were on this regard. There were Kanban board on place, team had daily meetings and weekly demos. There were electronic story tracking and people were generally really aware of how to build software the right way. Last but maybe the most important thing is that team was constantly questioning the ways of working e.g. the team found out that daily meetings with whole development team didn’t play out very well. Team decided to split it so that each feature team holds their own stand-up meeting and then the whole development team had kind of scrum of scrums stand-up meeting after team spesific meetings. Last iteration of this at the moment is that those scrum of scrum style meetings were not necessary to have each day so we have them every second day. We will continue to adjust this and other things in our daily routines. At Smartly you get to work with talented and bright people who all are professionals in their own fields. Working with the best people allows you to learn faster and it also makes it easier to build processes that support efficient software development. As a consultant you may end up working with whoever people there might be working for the customer. Sometimes there are brilliant people and sometimes not and you need to handle that.

One of the things I personally value a lot in a project is minimizing the feedback loop. I’ve worked in projects where it can take months (no kidding) to see your code live and get real customer feedback. It can be frustrating experience because when you build something and if it takes long to get feedback, in the worst case you forget why something was done and it’s hard to fix it afterwards. Best scenario is to get instant feedback and this is what we try to achieve at Smartly. We have almost instant release and deployment process in place. When you finish a feature and find someone to review it, you tell Hubot to deploy your feature. If tests pass and everything goes well your code gets deployed to production almost instantly. This way we can deploy to production multiple times a day and start getting real customer feedback. Also makes developer happy to deliver stuff. We also like to keep our developers close to customers so we all do support every now and then so we have first hand information how things are going. This is awesome way to see how customers use the software. And what would be better way to get feedback than customer telling you that she loves the new feature that you deployed couple of days ago!

This is it for now. I’m planning to write more tech and worklife related blog posts in the future. Follow me, if you’re interested in reading more about what we do at Smartly and how we work.

Btw. We are looking for more awesome people to join our ranks, so check out our open positions or drop me a line!