Start building!

Most software engineers probably remember times when they start a project and everything seems to be getting built fast. Then the project grows and all of a sudden making a simple change takes a day, then two, then a whole week. Why does it happen?

The life cycle of a software project tends to be similar to the following, with the reactions from both engineers and management attempting to fix the issues as they occur.

The beginning

There is not much code. Everybody understands most of it. There are no dependencies. If anything breaks, it is easy to fix, although it may be annoying. There are no clients who would complain if it is broken. Everybody also knows why things are built. At least, if there was a vision on what to build.

On a good team, there may be tests already in place and a rudimentary CI/CD pipeline. So things will almost never break in the first place. In some other cases, there is so much rushing that things already break often enough. Review processes may be put in place to mitigate the damage. It starts taking a bit longer to add any change.

Initial growth

There is more code now. Some people understand most of it. There are some dependencies. If anything breaks, it may take some effort to figure out the cause. There are some clients who would complain if something is broken.

On a good team, things would still not break that often, but it takes a little bit longer to implement any changes, because time needs to be spent on considering the newly built dependencies. In a more rushed environment, things start breaking that are difficult to locate. More dependencies may be added to "speed up" the development process. Note: some may even help.

Processes start evolving, the CI/CD will grow, docker may become introduced, if it wasn't already. Build times increase.

A more mature project, wherein mature signifies age

There is a lot of code. Most people only understand parts of it. If anything breaks, who you gonna call?

Time to stop here, because it is already clear where it is going. The project will slow down almost inevitably.

Where does the time get spent?

In a relatively common project setup, the time gets spent between many things. Where most of it goes depends on the project and the people working on it, but just to give an idea, these tend to be the hurdles to overcome before a change makes it to the user.

• Meetings and communication

  • Discussing the problem, needs of users
  • Architecture discussions
  • Code reviews
  • Urgent requests from management
  • Updates for the sake of update
  • Talking directly to a client (a rare one!)

• Distractions

  • Changes in direction

    • Let's not build this, let's build this instead
    • It is not clear why it is being built, let's stop

  • Requests for help

    • Cannot find documentation
    • Cannot understand code
    • Cannot understand why something (used as a dependency) is not working as expected

• Implementation

  • Build time
  • Local test run time
  • Startup time
  • Time spent on reading the code to find the right code to update
  • Time spent on writing the code
  • Time spent on writing tests for the update
  • Time spent writing documentation

• Deployment process

  • Waiting for the build
  • Waiting for the tests
  • Waiting for the deployment after merging
  • Trying out a few smoke tests on production (or not)

• Monitoring/tracking

  • Setting up monitoring, sometimes for specific pages
  • Setting up tracking and statistics

That is quite a few steps. Sometimes there are more, but it covers a lot of it. A variety of software development methodologies focus on eliminating or optimizing for one or another step in the above list, but all of them matter.

In the end, the time spent when implementing anything, the time spent is the sum of all steps listed above.

Where can Eye Closely help?

As an application, Eye Closely can help with monitoring the entire website. For all the other steps that precede getting something, please stand-by for the next posts that will detail on what strategies are used in Eye Closely to minimize the time to production.

Summary

The speed of development in any software project depends on the sum of variables, all of which need to be optimized to maintain a fast-moving project.

The next post will be about speeding up the deployment process and how far it can be stretched while keeping the project simple and scalable.