author-image

Kevin Riedl

16 min read · 29 June 2024

Software - a Breathing Organism

Software is never finished. Yet most companies price and treat the project that way. How to avoid putting your budget on fire while making your users so happy they tell their friends.

Did you know that we have Software Architects in tech? Software Developers are also often called Builders or Engineers (more experienced developers). There is a reason there are so many parallels between Tech and actual civil engineering (such as constructing buildings, etc).

So, what are the parallels and what can we learn from them?

Working on a Web3 Project?

 Challenge your Product

Civil- & Software Engineering Parallels

If you think about constructing a building 🏗️ - you need to..

  1. ..plan what you want to build, do resource planning, etc.
  2. ..analyze a variety of external factors to make sure your project is doable within the context of the project.
  3. ..design the interior and exterior - and how you want to structure rooms, where to place windows etc.
  4. ..then actually build it from the ground up.
  5. ..then integrate it into existing infrastructure such as the internet, energy grid, water network, etc. and, test if everything is secure, and as planned.
  6. ..then maintain the building, possibly renew parts at some point, or even extend the building if demand grows.

Software Lifecycle We have a relatively similar process for developing software solutions - this process unavoidably also comes with the same risks and challenges.

In the illustration, you see the typical software lifecycle. Every feature and every milestone undergoes this lifecycle. It always starts with the plan of what you want to build, and ends with maintaining the current feature set.

Once your users come up with new feature requests or your software becomes too old to compete in the market the cycle repeats.

Don't skip a phase

Every step in the software lifecycle is vital for success. Let's go through it one by one.

1. Neglecting the Planning phase

Would you initiate the construction of a building without a plan? Probably not.

This phase involves defining the project scope, goals, and requirements of the client, and creating a detailed project plan. There are two major approaches to building software products: the Waterfall method and Agile project management.

The waterfall approach requires both the software agency and the client to specify an exhaustive list of functionalities and to have the complete plan fully-fledged out before the first line of code is written. As you can imagine this is very challenging, especially as requirements may change in the process due to new market feedback or other external factors.

Waterfall project management

The majority of software projects use the agile approach to stay within budget and to react to unforeseen challenges. But here comes the kicker: Most companies take the Agile methodology as an excuse to not plan at all. Let's have a look.

Agile project management without plan

Using Agile project management as an excuse to "just start" the project and not doing proper requirements-engineering will undoubtedly kill your project. The developers will most likely fail to properly prioritize most urgent features. And in the worst case, the software won't even work - and if it does at a significant delay. If you work with an external software provider, then make sure they have a cohesive process and reporting in place.

Agile project management with plan

Agile project management still requires a plan. The major difference to the waterfall method is that we have regular feedback cycles, iterations and realign on the priorities every day, week and bi-weekly, etc.

Quote Author Image

"Failing to plan is planning to fail."

2. Skipping Analysis

In this phase, the software agency works with all stakeholders to define the specific features and functionalities that the software should include. Skipping this phase will likely result in desired features not being built within the planned budget.

In short - an unhappy client. Detailed requirements help to properly budget the project and help to align expectations which is crucial for long-term project success.

3. Letting Design slide

User Interface Mockup There are 2 types of design in software. The first one is for designing how the user interacts with your application. This includes simple wireframes, "mood-boards" and mockups. The best and easiest user interfaces have been thoughtfully designed to make your app as easy to use as possible.

Just like with any profession - if you want to have something great - work with great people. If you are ok with mediocrity or have a tight budget, then this of course might be an acceptable trade-off for the start.

The second type of design is Software Design. Looking at all software components from a bird's eye view is called Software Architecture.

But what is it? Let's think about Netflix - the famous streaming provider. Netflix's software architecture consists of thousands of software services that interact with each other to cover everything you can do on Netflix. This includes registering a new account, logging in, streaming a movie, and payment services for your subscription for example.

Each of these services also has been carefully designed to be able to keep up with the amount of user requests and to recover in case of unexpected errors. You can find an exemplary software design of an imaginary feature below.

Software Design

Properly architecting your software and designing its components can decide whether your software becomes unmaintainable and very difficult to extend by new features. Consider a proper software design an investment into the future of your project - to avoid the infamous technical debt.

Building a Web3 Project?

 Book Free Consultation

4. Rushing Implementation

In this phase, the software developers actually write the code. As part of the agile project methodology, the software developers should regularly report to the client and give them an opportunity to leave early feedback. This enables short-term changes that would otherwise need to be changed at a much later point in time. You might like our blog post related to this subject matter: "Why people think Software Agencies suck"

5. Sacrificing Testing & Integration

Cost of TestingThe testing phase takes time and resources as every phase in the software lifecycle. But nothing will break your software faster than not having sufficient programmatic tests. We also got a blog post about software testing: "Test Driven Development".

As part of the testing, it is also crucial to make sure your software is sufficiently integrated with external software that your application is dependent on. A Web3-specific example here would be oracles - getting off-chain data into your smart contract. Although this is part of the previous phases, the integration and test on the real mainnet blockchain should be tested as well.

6. Forgetting about Maintenance

We just heard that software has dependencies - software that has not been developed by your software agency but by thousands of independent developers. In addition, your own software application evolves as well - new functionalities might be demanded by users, users will discover bugs and dependencies that need to be updated.

The better of a job your software agency made with the previous phases, especially with gathering requirements and software design - the easier and cheaper maintenance will be. There is no software on earth, that does not need maintenance - except, of course, nobody is using it but I guess that's not what we want. Some software agencies dislike maintenance, so make sure your software provider is willing to do that.

Final thoughts

Always make sure that whoever software engineer or software agency you're working with is aware of these software lifecycles. And most importantly is willing to support you during the full process.

You can skip or neglect some of these phases, but this will undoubtedly be more expensive long-term and slow down new feature deliveries at a later point in time - assuming the initial requirements can even be accomplished with a faulty process.

You may also like..
author-image

Kevin Riedl

16 min read · 29 June 2024