Jun 7 2020
What painting a shed can teach us about writing software

What can we learn from painting

With the world being on lockdown I recently had time to finally get around to painting my garden shed. It’s a job that I kept putting off because I wanted to do other things (like playing Ghost Recon Breakpoint).

Anyway, I finally started to paint my shed and as I worked away on painting the shed, I thought to myself how we approach something like painting a shed can be job could be applied to software development.

Thinking about it there are five rules that you need to apply to paint that also applies to software development. These rules are:

  1. Always prep before starting
  2. Have the right tools
  3. Plan before starting work
  4. Don’t move on to working on a new section until you’ve finished what you started
  5. Practice makes perfect, well better

Always prep before starting

Before starting any project you have to prep. For painting a shed, you have to make sure the shed has been swept, removing all dust and dirt. Then you have to smooth down any splinters or rough edges and then make sure you have planned how you are going to tackle the work ahead.

Have the right tools

If you start trying to paint a shed with a small paintbrush, one that you’d use for painting a small picture. That would take you ages, and after a while, the brush would be useless through it not being the right tool for the job ahead.

The same can be said for the tools you use to build your software. In the Angular world we have tools like the Angular CLI, Karma for tests, WebStorm for writing your code. You can write an Angular application using Notepad, by why would you. Use tools that not only help you write code, but enable you to write the best code you can.

Plan before starting work

I’m not the best painter in the world so I need to spend a bit of time before throwing paint at a shed I need to make sure I’ve spent a bit of time planning what I was going to do.

So Ive learnt of the last few attempts at decorating that it I need to put in some planning before getting started. This involves working out what part of the shed I was going to paint, where I was going to start and what section of the wall I was going to paint.

Having a good plan for what I was going to do before getting started helped me do a better job this time than I had before.

This planning before you get started on a piece of work should be applied to development as well. Whenever you’re about to start a new feature or implement a new section of an application, spending a bit of time planning what you’re going to do before diving straight into the work is always recommend.

This planning , even spending a few short minutes thinking about how you’re going to tackle the problem in front of you, will save you so much time and probably lead to better written code.

Don’t move on to working on a new section until you’ve finished what you started

One thing I decided to do this time was to paint the shed section by section. This way I could keep track of where I’ve painted and move from section to section once a section had been completed.

Again this approach can be applied to development as well. When building a new application, it can be easy to start on one part of the application then quickly move on to the next, just to get the basics of the app setup. To give you the impression that you’ve got a lot of the application up and running, but this is not a great idea. Say you have a target of having 80% of unit test coverage for your app, but you’ve gone off creating screens, adding services and setting up routes. You’ve done all this work and no tests. Now you have to go back to where you started and try adding tests. But in your rush to get a lot ‘done’ you’ve written code that is hard to test!! So now what do you do, spend more time trying to work out how to write tests for code that is hard to test. All that time you think you’ve saved get all these sections done, now you have to spend more time trying to setup tests.

So it’s worth making sure that you have the section your working on completed before going on to the next feature. Yes, from a project perspective it can look like you’re getting a lot done. Your sprint tickets are being moved into In Progress and Done really quickly, but is the quality of the work you’ve done that good? Making sure you’ve finished to a decent level a section or feature of the app before moving on to the next will save time in the long run and the quality of the work you do as a developer is more impressive than moving tickets on a sprint board.

Practice makes perfect, well better

Finally, the thing I did learn while painting my shed was, while I don’t paint sheds as a living I did notice that this time I was doing a better job than the last time. Each time I had to do some decorating at home, it was a perfect opportunity to practice my painting skills and the more times I did this the better I got.

Now I admit my painting skills are not great, but that shouldn’t stop me from trying. The more times I try, the more times I could practice and through this I was getting better.

The same can be applied to web development, the first website or web application you build won’t be perfect, but only through trying over and over will you get better at writing good quality apps. It’s better to keep practicing and trying this leads you to learning new and better ways of tackling problems. Leading to better apps for your users.

A great book on this idea of practising and getting through this barrier of thinking that you’re working isn’t good enough is Steven Pressfield’s book The War of Art where he talks about the resistance we feel putting our work out there, but through getting through this resistance and keep putting work out will we get better at our work.

So while I’m not a great painter and decorator, though taking my time, working bit by bit, using the right tools for the job and not putting off getting the work done. I’ve managed to do a decent job on my shed. Taking this approach can also lead to good quality code, leading to good quality applications.

Stephen Adams 0 Comments
Nov 27 2019
Agile doesn’t work if your code isn’t

I’ve worked on a few software projects over the years and many of them have been run within an Agile environment.

Agile is a software planning methodology where the work is carried out in small chunks, the requirements are listed in a backlog, which is worked on through these small chunks of development time, called sprints. At the end of a sprint a piece or pieces of work are delivered. This allows software teams to move quickly through the software requirements, be able to deliver software quickly and be able to handle changes in requirements as they go, become agile in the direction they move forward

This is the general theory, unfortunately from what I’ve seen over the years teams that have a Agile project management methodology, but who’s software is still built using a pre-Agile approach struggle to deliver what Agile promises.

The reasons for this are, if your software architecture is still very closely coupled, meaning one layer (the front-end) can not be fully developed in separation from the backend. It is extremely hard for the developers to make quick, fast changes because they run into numerous issues. They may have to wait for the backend team to make a change to an API in order to provide data that the front end needs, if there is no tests in place there isn’t the time for tests to be added or new tests to be written. This can lead to bugs coming into already delivered software and as the team moves forward in their Agile way, the time available to fix bugs and write tests gets less and less, leading to the possibility of the bug list growing and growing.

Implementing an Agile software project management approach is far easier than moving an large enterprise application to being able to be worked on in an Agile way. Arranging two week sprints, setting up a task list board and having a backlog and your ready to go is far easier than getting your software setup to be Agile, but it is possible.

The key to solving these problems is moving the architecture of the project to a more separated approach. Where each layer can be developed on independently, and doesn’t rely on another layer having a new piece of functionality in place before work can start on a new feature.

Dividing the work in a sprint between delivering features and updating the architecture of the application to be more separated allows, over time, the project to become more in line with an Agile approach. The developers can amend the application so the front end can run in separation from the backend. The UI layer can be written in separation from the front-end layer, allowing the UI to be mocked to show users how new features could look so feedback can be given earlier in the process. Leading the feedback being added into the sprints work load before all the other layers have implemented a feature.

Modern web tools can help

Using more modern web frameworks and tools can help. Using something like Angular to build just the front-end Logic, while the UI is built by another developer. This UI can be what is demonstrated to the end user in sprint planning when gathering requirements so the entire team knows what is expected. Using frameworks like NgRx and Nx workspaces allow the Angular developers to move the Angular code add to a consistent pattern that all the Angular developers on the team can follow, leading to a consistent structure allowing any of the Angular developers to work on any part of the application (especially if this is a large enterprise application) without much ramp up time. This can be extremely beneficial for distributed teams or teams with offshore developers.

Tools like NestJS or Node can allow the front-end team write mock endpoints which they can use to build from, while the backend team works on the real production ready APIs.

If the structure of the response is agreed upon, in sprint planning, then the mock APIs (which could return static Json) should be fine to get started building against.

Agile Can Work

Agile can really work as a way of managing the workload of a team, but without an architecture that can support quick code changes bugs will linger and more and more time will need to be spent on fixing issues.

An agile project management approach with a flexible approach to the codes structure will lead to applications that can be delivered quickly.

I like the Agile methodology, but we need to consider the structure of our existing code before going head first to a fully agile approach.

Stephen Adams 0 Comments
Nov 14 2019
IR35 and it’s possible effect

IR35 is looming over all contractors in the uk, it could be in place in April 2020, and there no doubt if it does come into full effect, then it will change how contractors operate.

For those who don’t know about IR35 then it is new legislation where the uk government is trying to stop those contractors who have been working as full time employees but still being paid on a contractor rate.

The idea is that if you have a contract where you are employed to work for a firm in a role where a full time employee could actually do the role, the. You as the contractor needs to prove that your contract is actually outside the IR35 guidelines. If it falls within. The IR35 rules then you will have to pay the same level as tax that a permanent employee pays.

This is a high level overview of IR35 it is worth really looking into the official government websites in order to find out more about IR35.

How IR35 could change how I work

For me if the IR35 rules do become law then it will change how I currently work. I would have to only take on contracts where it is clearly set out what the project is be working on and when it is expected to finish, to show that I am only employed to work on that project. Another way to show that the contract is outside IR35 I’d need to show that I’m not needed to work onsite, instead I’ve been employed to work as a consultant on a single project, and it’s up to me on how and where I work on this project. So if I want I could say that I work only from my home office or a specific work space. I’ll also need to show that I’m using my own equipment to work on this project, though I could see this being an issue for some large organisations where for security reasons they want people working on their projects to use equipment the company provides.

These changes, aren’t to much of a change for how I currently work, I think it makes me work in more of a freelance working model than a contractors who just works as a extra resource for a company who comes into the office day to day and just works on the same project.

How will this be effecting recruitment agencies

If IR35 does come in it could have some serious changes to how recruitment agencies work. They will have to now find developers who can work on a project instead of getting in an extra resource for a company. It will be interesting to see how they will be changing or will they leave the contractor market altogether and just concentrate on sourcing full time employees?

The contracting market is going to be interesting in the coming months, does this mean I’m looking to go permanent? Well, no. I enjoy working for myself and if the IR35 rules are changing to me needed to work more as a project specialist then that suits me.

I enjoy working on Angular and Angular based project, so if you are looking for an Angular specialist to work on your next web application project, feel free to contact me.

Stephen Adams 0 Comments
Mar 6 2015
Distributed teams

Today I’ve been working from home, thankfully the client I’m working for sometimes allows me to do this if I need to. I was thinking about remote working and how it has changed and grown so much over the last few years.

Back when I started in the web industry many years ago, one of the first places I worked at had a small team for this web stuff, and eventually they went off on their own and I was asked if, as the junior developer, I’d like to go with them on their new adventure.

So for the first few weeks we as a team of three was a distributed team, each working from their homes. Back then all I had was a dial up, a old computer with a CRT (remember them), Dreamweaver and FTP. Whenever I need to talk to another member of the team, we’d email a time to talk. Then I’d unplug the telephone line from the computer, plug the phone in and speak to my team mate. This was about 14 years ago so mobiles were just coming out.

Now sitting here I have a laptop, wifi, Dropbox and Slack/Glitter all keeping me in touch with not only the other members of my team, but developers all over the world. I can sync all my changes through Dropbox, so when I’m back in the office I can check in to the build server, all the work I’ve done here.  Through things like Slack/Glitter I can speak to other developers on any project I have in Github.

In America it looks like the distributed team approach has really taken off. In the UK businesses are not as open to the idea, mainly established businesses are not keen on this model. New startups are looking at this approach, but being in a smaller country compared to the US, I think UK firms are still new to the distributed model, which is a shame because now it is some much easier to work this way. I’m sure top developers are put off by a role when they see how long the commute is, if more companies were open to this way of working then they might find the best developers for their team/project.

Stephen Adams 0 Comments