I would recommend reading Part I and Part II of this series before moving forward.

…and the email continues…

And this gets me back to my original answer to your question.

One of the critical issues that pushed out our timeline more than any other was our relationship with our developers. Another was our understanding – or lack thereof – of the development process and methodologies. Early development was hampered by our misunderstanding of the Agile development environment adopted by our developers and was further complicated by disagreements around software ownership in an Open Source model.

These misunderstandings and disagreements heavily and negatively affected not only our relationships with the development team but also seeded distrust of the software itself that percolated throughout our Office Team and led to many unnecessary delays in development and adoption. I should say that these misunderstandings were far from one-sided. Ultimately the original development company realized the unsustainable nature of their development practices and folded their business. Fortunately, their lead developer continued working on the BLISS project as a freelancer for some years afterward.

In the years that followed the breakup of the original development team, our own business faced many challenges in rebuilding essential infrastructure that led to shifting priorities around time and budget. These shifts hit our developer negatively, as twice we began our fiscal year with a financial commitment to development which we then later backed out of in order to divert funds to critical infrastructure projects.

This in turn led to our developer backing out of our relationship altogether – a major setback to the project that caused all development to stop for over three years as well as the accumulation of vast amounts of “technical debt” while fundamental updates to underlying architecture were left unattended.

Thus, after three years searching for and auditioning development teams, when we finally did find a team we were interested in working with, our first tasks had to center around critical updates that provided zero new features for end-users, but which had to be accomplished before any other development could proceed.

Lessons learned:

Create realistic development goals from the outset and manage those goals in discrete chunks (i.e. achievable milestones);

Before entering into a development agreement, make sure your team has a clear understanding of the methodologies and practices of your developer, and manage the project accordingly;

Developer relations are critical to the success of your project – do not take this lightly.

The other thing that this posts mentions and is mostly ignored by clients is Technical Debt. Clients think that Technical Debt is a concept made up by the industry to get more money out of the clients. As a matter of fact, keeping a close watch on Technical Debt helps keep the costs low in the long run.

Click here for more details…

At BoTree Technologies, we build enterprise applications with our RoR team of 25+ engineers.

We also specialize in Python, RPA, AI, Django, JavaScript and ReactJS.

Consulting is free – let us help you grow!