Sunny Nagi

Solutions Architect who likes .NET Framework and Cloud Computing, Amateur Photographer loves his Gadgets and Cars



I have been involved with a really complex web application for past year or so. The application itself is quite straight forward but it is the complexity of UI, business logic and interactions with various third party interfaces that makes it quite complex system.


In recent weeks the development team has been plagued with all sorts of issues trying to get the application to work and behave as expected in Production Environment.


The issues started becoming visible when we moved the application into production environment and the various infrastructure bits started to fail.


As developers we are hard wired to trust our development environment, anything that we develop we have full control over it. And not even for a minute we consider that the application and its dependencies are ever going to fail.


In our case we came across a raft of failures in the production environment where a B2B interface goes offline and it is critical interface that eventually stops the business process.


Also there are scenarios where we receive response values that we never accounted for and application doesn't knows how to deal with them.  These silly issues caused our application to break down and stop the process. The business process was anyways not going to be completed but it was the amount of time that it took us to investigate the issue. And another contributing factor in causing use even more headache was our lack of access of production environment.


Upon a close investigation of the issue in hand what I discovered that issue could have been quite easily picked if during development process we had validated data that we receive from various interfaces and from user screens. It goes back to the basics of development which often modern developers tend to forget as they are too busy doing more advanced things with new toolset or technologies. 


The basic ground rules for any software development process is never ever trust your input data. You should always validate and verify the data that comes into the application - if it is data from a service, data from form inputs.


Here are some of the best practices around validation of data:


  • Never remove server-side validations, it is cool to validate on client side but server should still validate all data when it is posted back into the application


  • Always specify Field lengths explicitly, never allow user to enter in as many values as they can.


  • Provide helpful validation feedback to user, it should always clearly state the errors and if possible provide ways to fix them


  • Don't let users think what is required and what is not, clearly mark fields that are required


  • Validate all data that gets exchanged between B2B services. Also ensure that data aligns with the field lengths specified in the database. If there's any differences try to adjust the field lengths.


  • In case there's a failure or error within the application, handle it gracefully and do not show any sensitive data as part or exception message.





alt text

I have been working on recovery of a .NET development project gone wrong.

I joined development team at a very late stage of project to get system over the UAT phase. The system itself is complex, some of the core code has inheritance depth of up to 20 levels (yep someone went over board). It’s quite strange as on surface it is a simple web application with few screens, some business logic and few data tables in the background.

Question needs to be asked why this complexity, well often we come across developers who don't understand YGANI (You Are Not Gonna Need It).

The principle of YGANI is fairly simple to understand which states that you should delay the decisions that you need to make today to tomorrow.

This application is a classic example of over engineering beyond believes, that again goes against KISS principle. The level of complexities that I have come across in this application along with the choice of poor components makes it a dog to run.

The client was promised a sports car with all of the bells and whistles but what they got is old school looking rusted lemon which is dog to run and is nightmare to maintain. Since the original development team had moved on the team managing the application were fairly junior who have been transitioned into support role to look after the pending defects.

With the level of complexity involved in simplistic of the features was enough to drive fear among the support team. After going through number of people to make this work, management soon enough realized that they need someone more senior. When I joined the project first thing I questioned was why ?? Why are we doing it this way? And soon enough I also realized that this maintenance time bomb ticking to explode. We suggested radical changes not only to the core of the application but also to the ALM itself to streamline and deliver quality to the customer.

Well I have been on this project for almost 3 months now and we have concluded that simple salvage job is not as simple as you would expect.

The shinning bright star of this whole journey has been the development framework that I have been developing for a little while now. Built on entity framework code first and using simplistic implementation of some core design patterns we have got junior developers picking it up and working on their components quite easily.

In conclusion all I want to highlight is that yes we all are techies, smart people capable of making sound choices but often due to our love for a specific technology and pattern we forget to look at the bigger picture that is to solve business problems with simple yet elegant technical solutions.

Whenever I am writing code I always have this thought in the back of my mind - someday someone else will get to work on what I am writing now and I don’t want them to feel what frustrates me today. Writing good maintainable code is not a privilege but it is a moral responsibility.

Software Architecture

Software architecture has become one of the hottest topic in last year or so. I also moved into software architecture role at the start of last year. It is very different world but very interesting as you get to deal with the problems first up and come up with a solution that is always best for business and not necessarily always best technical solution.

Here are couple of really good articles which highlight some of the challenges that are faced with architects

The Hidden Roles of Software Architects

Thoughts on being a Solution Architect