On Software Development and Client Work

Posted by Andrea Bizzotto on February 4, 2015

Disclaimer: the views and opinions in this post are exclusively my own. I’m likely wrong, and that’s fine.

Lately I’ve been thinking a lot about how I can be most productive in my work and how I can maximise my value to my clients.

I believe that there are a number of important factors that come into play when aiming for productivity. Some of them are technical and some human. Here is my attempt to summarise both:

Use the best software tools and hardware

This sounds obvious, but as a mobile developer I sometimes run the ‘compile & run evaluation loop’ dozens of times per hour, so I greatly benefit from fast hardware that minimises build times. Using a powerful IDE is also a great productivity booster.

As good developers are scarce and expensive, they should spend most of their time creating great products, and as little as possible in repetitive tasks and things that can be automated.

For software companies, having developers rebuilding code over and over on slow machines does not make sense from a cost perspective.

Adopt best practices

In my experience it’s been quite common to see projects with a lot of technical debt and poor underlying architectural foundations. From having architectures with massive monolithic view controllers to copy-pasting code across the codebase, to not following basic principles of good API design, there’s plenty of things that can go wrong and cause the codebase to rot. This makes projects very difficult to maintain and especially in organisations with a high developer turnover it can lead to very serious problems.

I believe that while experienced developers can smell bad code and fix it to some extent, getting a big software codebase from a poor to a very healthy state is something that requires a lot of work, company-wide, and establishing a better culture is sometimes required for long term success. Even then, we work in an industry that often redefines best practices, so how do we strike the right balance?

My view is that being pragmatic is the best way forward. I believe that there is such thing as good-enough in the software world. ‘Ship early, polish continuously. (Perfection never delivers)’ is a concept that comes to mind here.

As there is an enormous amount of literature on good software practices, knowing it all is not an option. As we always work on projects with deadlines, I think the best we can do is to follow some principles (in no particular order):

  • Always write code for other developers to read (code is more often read than written)
  • Keep it simple, do not over-engineer, but think about reuse
  • Document the Why, not the What
  • Program to interfaces, not implementations. If you want to take this a step further, define your types clearly and make it really hard or impossible to use your types incorrectly. This way the compiler will do a lot more work for you and you will need less tests.
  • Make good use of functional programming concepts, favour immutable objects. This minimises application state and reduces side effects.
  • For client-server systems, really understand what should be done server side and what should be done client side. Do not do ‘hack’ something complicated on the client if it’s very simple to do it right on the server and vice versa (if you ignore this, things will break and will bite you back).
  • On mobile apps, UX is paramount. Really think it through (I really like to use the two tap rule as a guiding principle for this), before writing a lot of code.

Final considerations

While I’m no authority in the world of software development, I have learnt a lot from my previous mistakes and find the principles above very useful. For me it is very rewarding to help clients deliver better products and improve internal coding practices and their engineering culture.

Personally, I love to keep up to date with latest technologies, read a lot of open source code, and write some too. My favourite way of knowing that I’m becoming a better developer is to look at the code I’ve written six months back, and see it as bad code. If that was not the case, it would mean that I’m not improving.

If you liked this post, you can share it with your followers or follow me on Twitter!

Get an email when I write a new story. No spam. Ever.

* indicates required