Skip to main content

Lessons from a greenish-field project

As consultants most of our work involves either PoCs or going into brownfield projects. However, recently I had the opportunity to go into a greenfield project, and below are the lessons I learnt.

Don't over engineer

The stack that I was using was pretty standard. Entity Framework + MVC5. However, at the end of the project I found that the architecture that I have created was overly complicated when it need not be. Using an ORM such as Entity framework means that you already have a pretty solid data access layer in-place. What I had done was abstract this data access layer away from the business layer so that the business layer is not calling any Entity Framework code at all. I found this design to be too complicated, because the layer that abstracts EF was basically a wrapper that pipes into EF. Next time, I would simply call EF from my business tier. There is nothing wrong with this as EF already implements a repository pattern.

Don't prematurely optimise

Another error I fell into was that I had optimised too early. The result of the added optimisation meant that some of the code wasn't as readable as it should have been. Because this code was added early on in the solution it meant that it can potentially become code latter on that no one touches because no one really understands and is too scared to refactor (legacy? :P ). This is the type of code we do not want in any code-base.

Performance tests and logging

Entity Framework makes it quite difficult to do bulk deletes and bulk updates without doing any round trips, so I tried to optimise for this earlier on (as stated in the previously, I wouldn't do this if I started another project). I believe there is more value in creating performance tests than there is spending time doing premature optimisations. Why? because performance tests give you an initial benchmark to compare against, so that when and if optimisations are needed we have the right benchmarks to compare against. A leader who has numbers on the product he/she leads is a leader who knows the software product well.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?