Over the years I have had a lot to do with new projects and new customers coming on board with Sandfield. Each time I deal with a new client or project, I notice that our way of doing things works very well. We also learn new things from the customer’s way of doing things. Taking over an existing project requires a different approach as compromises are required.
Recently we took over a reasonably large project from another developer. The client was not happy with how things had been progressing - things were long overdue and the general quality of work was not up to scratch.
Background
Things started out well with the client and previous development company. As the project grew, things became harder and more difficult for the small development company to handle. Employees became unhappy and left. As new developers with little experience joined, they were put on this big, already late project. Everyone tried their best, but because of the high developer turnover and exacerbated by poor or variable coding standards, things got worse and fast.
Things learnt
I see a project like this as a fun challenge (in a sadistic way some may say). I always learn from other developers, either new ideas or things to avoid (see examples section below). By taking the good and discarding the bad, it improves our skills and also confirms our practices. It builds our capability to pick up other people's code/projects, and get them knocked into shape and moving ahead.
Keep things as simple as possible.
While working through the code, I also realised the importance of having your developers stay with your company. There must have been 10 different standards throughout the project. This makes maintaining and understanding the code extremely hard. Make sure you hold on to your developers. Keep them happy! If you have a good set of standards consistently applied, you should be able to get just about any of your team of developers working on any project in a short space of time since the only thing they need is domain knowledge.
Once we took over this project I migrated the source code to Git and required our team to submit code in the form of Pull Requests. This allowed me to review their code (and compare their changes to the unchanged code) before merging it into the master branch. This made it easier to enforce Sandfield standards, especially for newer less experienced developers on the team.
Initially, the project was much harder and more stressful than it needed to be because it was long overdue, far over budget, and the clients were unhappy. The only way to work through this is to always be very positive, not panic and work to a smart plan. It’s also extremely important (especially in the early stages) to underpromise and overdeliver.
Keep the client happy by giving them control and visibility.
Keep things as simple as possible. Get a good project plan with a timeline set up and give the client as many updates as you can so they have a very clear picture of how things are going (that is the reason they came to us right?). We also found that grouping development items into weekly releases made a lot of sense in this case and gave the customers a lot of flexibility and visibility. They could pick which items they wanted in the next weeks release. This worked well for the client as they could have a constant stream of improvements tuned to their clients priorities. They could test functions as they were completed and demo the functionality with their clients frequently, which showed good progress and built confidence and trust.
Examples of what to avoid as learned from this project
Most data stored as XML files on disk
A lot of their data is stored on disk as XML (combination of data in SQL and as XML files on disk) files making searches perform very badly. Each entity in the database has a separate file on disk which is linked to a simple SQL database entry by file name convention only. This data is only short text data, which should have been stored in the tables directly.
Entity framework and using extremely large lambda queries
The previous developers relied solely on Entity Framework for all queries which causes bad performance across the board. Very large lambda queries were written, and converted into objects, which are then filtered and ordered in C#. Instead of Entity Framework and large lambda queries, we would normally create simple SQL stored procedures. These output the data in the format we need for the page, so we can easily render it to the page.
Making code so generic that it’s complicated
Many parts of the system are built upon many generic methods and obscure functions, which makes the codebase very hard to maintain. We believe in keeping things simple, instead of creating many custom objects, overusing generics, and heavily relying on inheritance, we would rather create many methods each performing a single task.
Simple code is easier to modify, easier to extend, easier to support, and more likely to be bug free, which makes for happier customers.
Not having experienced people on the job
Teams of unproven or junior people can end up making disastrous choices. At Sandfield we always have very experienced people who direct the development, set standards, review work and make important decisions based on proven approaches.
Conclusion
The key point of this article is to show you some of the things that we learnt from taking over a project from another client. There are many different scenarios, and this is just one.
Keep the client happy by giving them control and visibility. Set standards for the project early, and hold on to your developers by keeping them happy!
