BLOG

From Plank to Ship as You Sail Along

by Sysco LABS Agile 3 August 2018

In this Innovation Session, Ishan Madhusanka, Theekshana Dilshan, Dilini Mampitiya, Nethmi Hettiarachchi and Shashika Gunasena took us on a trip to the high seas. The topic – “From Plank to Ship as you Sail Along”.

Is it possible to build a ship, from a plank while you sail? Well no, that borders on the impossible, but if you think about it, that’s exactly what you do as Software Engineers building a product. You build the system, part by part, release in iterations, and slowly build towards your final objective.  By comparing the building of software to the building of a ship from a plank while sailing, helps to break down the software development process.

 

Know Your Destination

There’s a popular saying amongst sailors, “If one does not know to which port one is sailing to, no wind is favorable”. What this means is, if you just go out to sea, with no clear vision on where it is you want to go, no wind can possibly take you there. You’ll just be adrift. Knowing your destination gives you a clear direction on where to go. However, simply pointing your ship and hoping to eventually get there is a recipe for disaster. When you know where it is you want to go, you need to plan out your route. Planning out the route includes checking the weather, doing research on the path, checking if there are dangers, and setting a plan on how to tackle them.

In Software Development terms, this can be broken down into two words. Vison and Roadmap. Building Software without these two is simply like crossing a busy road blindfolded. It’s not going to end too well.

When Software Engineers start building without having a clear idea of the end-product, the end-result will just be a garbled mess. A clear communicated vision and a well-defined roadmap will help you think about what future releases may hold, and knowing that helps you to code now, for an easier integration in the future.

 

Upfront Architecture

There’s no way that any sailor can just set out on dangerous seas without a proper way to deal with the conditions. A base architecture is definitely needed, and with a good base, you can adjust as you go according to the conditions at hand.

In Software Engineering, the concept is pretty similar. Before going about making your product, a base architecture is needed. There are a few approaches to this:

  • Build-it-as-you-go – This allows you to quickly start the project but will usually lead to problems down the line. It probably won’t be very responsive to change since it was built in an ad-hoc manner. The system will lack Quality Attributes such as Performance, Scalability, Maintainability, Security, etc. This system tends to go down the route of “Accidental Architecture”.
  • Build a highly complex architecture based on the resources at hand. – This will be time consuming but is the way to go if your requirements are fixed. The downside of this is that unexpected changes could lead to long hours back at the drawing board.
  • Just Enough Architecture – The middle ground. By considering the context of the software, the road map, the vision, the requirements and the risks, a minimalist architecture is built. This kind of architecture allows you to be highly agile allowing you to respond to changes that may come up during the development of the product. Using this method, we can move on to the next point.
  • Evolutionary Architecture – Just like how we build software in an incremental way, the architecture is built using the same methodology. Using the “Just Enough Architecture” concept, you build on it in an incremental way so that it evolves, as time goes by.

 

Dealing with the Unexpected

Any sailor would tell you that sometimes things just don’t go according to plan. The weather for example, can change from being clear sunny skies, to storms that you could have sworn existed only in movies. Dealing with this is a matter of survival.

Granted, things may not be a matter of life and death when you’re coding, however you do come across hurdles which was not in the plan. Technology changes fast in the tech world. PHP was all the rage a few years back, before NodeJS; now, PHP is mostly a thing of the past.

To be able to keep up with such a rapidly changing environment requires being up to date, and constantly learning. Whenever a new technology comes out, taking the time to get a base understanding of it is what separates a good engineer from the greats. Of course, when implementing a new language within a team, the company should give its engineers time to learn, test and experiment with the language.

Basically, having a versatile mindset helps in dealing with the ever-changing tech landscape. Being stuck on a technology that you’re comfortable with will only take you so far. Those that have a versatile mindset are able to adapt quicker to changes, and that makes them far more valuable to the company.

 

Ahoy Captain (or Product Owners in SE Terms)

To confidently engage with the people up top, the Product Owners have to have complete trust in the work being done.

This can be achieved with the process used. The deployment pipeline generally serves this purpose.

The deployment pipeline usually has several stages: Dev, QA, Staging, and finally production. This helps mitigate the risk of something going wrong as much as possible. The code being pushed, has to go through testing at each stage before it’s finally pushed out. When the PO has the visibility to see how the release is progressing, he makes the call to push the code towards production once he is fully satisfied with the test stages.

A simple checklist could also go a long way towards mitigating risks.

  • Do all developers share/commit within the same repository everyday?
  • Is there a solid Test Suite in place to make sure that any code deployed will not break the main code?
  • If something does go wrong, can we roll back within a short period of time (15 mins or so)?

With these in place, the PO would have complete faith in the work being done, making it easier to work with them.

 

Dealing with Passengers or Customers

So, you have a chat with the passengers before making the ship. You get to work building it, and when it’s done, the passenger still isn’t happy because now he wants something different.

This is a challenge that Software Engineers deal with quite frequently. The changing requirement of the customer. The best way to deal with this is to loop them in on the work being done from start to finish. Don’t just gather requirements early and then forget about them till the product is done.

Looping them in at every stage of development will help them spot changes faster, resulting in a more perfect product being made.

The difference between these two methods can be summed up like this: Tweaks here and there vs Complete Overhaul.

As Software Engineers, we are capable of incredible things. Creating something out of nothing, then perfecting and evolving these product as we go. As a very famous uncle once said, “With Great Power, Comes Great Responsibility”, so let’s fully utilize the power bestowed upon us.

Leave a Comment

Tags