Complex Software Development Lessons Learned.

Now that I’m four months into what was supposed to be a one-month software project (nightmare), I’ve picked up some valuable lessons that I want to document for myself—and maybe they’ll help you too. I say this as someone with no deep software development expertise. I know some basic coding and have managed lighter tech projects, but I’ve never handled anything this complex. This project is unique and proprietary—there are no existing examples.

In hindsight, the things I’m about to share seem obvious. But when you’re embarking on a project—especially one that feels complex and overwhelming—it’s easy to lose sight of them.

Hire a Code Reviewer

One of the biggest lessons I’ve learned is the importance of hiring a code reviewer—someone who isn’t the main developer but regularly reviews the code and progress. Their value goes far beyond just critiquing the technical work.

• They act as a communication checkpoint between you and the developer.

• They provide an honest assessment if your developer isn’t performing.

• They ensure the project can transition smoothly if you need to replace the developer.

Without this, you’re at the mercy of one person’s word and skills, which is a huge risk. My approach here would be offering this role on an hourly basis to one of the candidates I considered hiring as the main developer. Expect a cost here, that is nearly as much as what you’re paying a developer.

Make the Developer Create the Plan

Another major takeaway is to have both the developer and the code reviewer create the project specifications and timeline—in their own words. Rather than handing them a pre-written plan, ask them to outline what needs to be done and how they plan to do it.

• This forces them to truly understand the scope instead of just agreeing with you.

• It helps identify gaps early on before they turn into major problems.

• It keeps them accountable to a schedule they set, rather than one you imposed.

Start On Your Own Server

Right from the very beginning have all work done on a server you own.

This might seem intuitive in hindsight but in the enthusiasm and overwhelm of a new project it is often easiest to just tell the developer to ‘get to work’ which means it starts on their server and then all development falls into place there. That creates a problem when you want to leave the developer.

Use Git Hub

Git hub keeps a log of all changes to files of the code and what was changed in the code. This helps you keep a monitor what is happening on development, how fast things are happening, and how much changes from each variation (expressed otherwise how much is actually happening relative to what you’re being billed for.

Require Change Notes Day-by-Day

From the beginning make the habit of having the developer send you a list of notes with everything that has been done day by day, or since the last point of feedback.

This works out better than just ‘checking to see what is done’ or relying on a task log. I dont know how to explain it further but something better happens when the developer has to say ‘this is what I accomplished.

Enforce Standards of Punctuality From The Beginning & Don’t Be Afraid To Replace Developer

In software projects replacing the developer is a headache and that is compounded exponentially when you have not managed the project to be handover.

This leads to getting lenient on standards and a downward spiral of such that ensures.

Following the steps of hiring a code reviewer, using you own server, and using Github puts in a position of being able to say “This needs to be done in 24 hours or I am cancelling the contract”.