Maintainable Code: Where did we go wrong?

Every Product, when started has this as a main objective. The code has to be maintainable. But, few years down the line if you look at the code base, you will be really wondering where did we go wrong?

Over the last 6 years, following is what i have seen as a pattern.

  • Most of the applications had a great solution structure. A Well thought out BO, DAO, DTO/VO, Services and UI Projects.
  • Reasonable implementation guidance (unit tests, documentation etc.. etc..) on how the code works, how to create something new.

Image: dan /

Great, But what about User Interface?
I guess, this is the place where most of the projects go wrong. Most of the good technical people with whom i worked with never consider UI as an important piece. So, typically you dont get to see implementation samples, documentation etc.. Obvious, Not much unit tests either. The effort which was put in creating a good solution goes for a toss as you start adding more developers in the team. People start hacking, logic leaks, not enough understanding of why things are done in a specific way, all this adds up to a big list of technical debts.

And finally comes MVC and Client side programming (JavaScript). Everybody talks about MVC, but not sure if most of the modern day developers understand why there is this M, V and C. Then comes this <%=%>. This is not only in the Microsoft community. I have seen best of the iOS developers struggling with this.

What should we start do differently?
1. Emphasize the importance of clean code in UI from day one.
2. Unit Tests, Unit Tests, Unit Tests…. Without this your code will be very hard to maintain after certain period.
3. Always start any project with sample implementations. Use that as a Reference Project and keep updating your reference project. New developers has to go through the Reference project, understand and follow.
4. Review your code base regularly (not just stop at services layer). Though this is a significant effort and need a very passionate person, doing this will definitely help in long term.
5. Coach your team members on the project architecture and design on a regular basis. Remind them about the technology vision during your  iteration planning every time (if at all if you have one :)).

Off late, Quick turn around/going to market quickly has become the selling point for most of the companies. Unless all the 7-ities are taken care in your project, it will be a nightmare to maintain the product for the next 10 years.

Happy Learning!!!


Architecture: How much is enough?

New product development is complex. One of the challenges I always see with development teams embarking in new product development is with the decision on how much architecture is enough.

I am sure we all have crossed the stage of BIG DESIGN UP FRONT (BDUF). It doesn’t work with changing requirements and I am sure all the software development effort we have today has changing requirements.

Industry has evolved over a period of time and has come up with an answer called YAGNI (YOU AIN’T GONNA NEED IT). Objective of this is that unless you need something, don’t build it.

Ok, what is the big deal on this?
ArchitectureLet us say you are building a house. Your foundation will form the structure for your building. If your foundation doesn’t support a certain design, there is no way you can build your house with the design. Meaning, it is very difficult to reshape the building once the foundation is done.

What is the solution for this?
There is no silver bullet. Balance is very important to anything one does, which I call as Minimal architecture definition.I see, people struggling with the definition of minimal architecture.

What defines a minimal architecture?
Minimal Architecture is not about your Visio diagrams or the colourful dubbas (boxes) in a PowerPoint presentation which can be checked in to your source control and helps you clear CMM or ISO Audit.

Minimal Architecture is something that,

  • Gets you started with your development
  • Enables development with minimal rework. One way to evaluate is the cost of rework during your development. I am talking about rework and not refactoring. I have seen many people calling the rework as refactoring (So that no one bothers to ask why there is rework).
  • Can evolve. Requirements will evolve over a period time, so does the architecture and design.
  • Is Testable. A Common question I see with stakeholders is that will this work? Human nature is that it will be very hard to believe anything until seen. Is there a way the architecture/design can be tested against the business goals so that it gives confidence to the stakeholders? Till it happens, architecture is a set of boxes aligned in a certain way J
  • Can scale. When I talk to product teams about scaling, the immediate answer I get is we do not know the requirement. True, you may not know the exact requirement as it is a new product. But you should be having some rough idea on the target market. Can your architecture address your current market and can scale if there is a future need. As I mentioned earlier, the structure of the house will be dependent on the foundation. If this is not done, there is no way you can say whether your architecture can meet your business needs.

Obviously, there can be more. In my opinion you will have a decent bet on the architecture if the above are answered and obviously you can scale. A little effort in planning can help you do much better during the development.

One of the things which I learnt is, all these has to be reviewed on a regular basis and it requires participation not just from the team, but also from all the key stakeholders.

Can this guarantee Success? May be/May not be. At least you will have a decent idea about your project and whether it can succeed. It can at least guarantee you that, you don’t have to bring in a consultant towards the mid/end of project to review your architecture.

Lean Architecture for Agile Software Development

Happy Learning!!!