I have not blogged for some time due to pressure of work, instead I tend to record ideas for blog posts on my kanban backlog… and they just add up.
Anyway, this post covers a couple of points highlighting different approaches to developing software which I have noted while working in the industry.
Code First or Database First?
I’m not talking about the Entity Framework methods of creating data models / databases here.
Is there more code in your system than there needs to be and / or is it more complex than it needs to be? This is subjective of course, but if so it is a major indicator that your database model / designs could be improved. A consequence of improving these designs is that the code becomes trivial. The purpose of any system is to translate the data model into concepts that make sense to the user. If the data model is designed with user requirements in mind, then the task becomes far simpler.
I remember 20 years ago a system I worked on which was for contract management for a big UK company.. This involved a major modification to an existing system. But management had decreed that there would be no contract table in the database….
System Requirements First or User Requirements First?
When making a change, say user A asks us to add a feature to system B, then there are two ways of approaching it.
- We could look at system B and work out which pages, methods etc. need to be changed, to allow for the easiest possible change with minimum changes.
- We could look at the design, the concepts of system B if you like from the users perspective and give them something that fits the requirement really well while putting the actual changes needed to the system second.
Many developers, especially the less experienced, when under time pressure are much more likely to think about the former approach and not care / understand too much about where the user is really coming from and what their needs are. The best systems often fill a strategic need for the user in a really elegant way, and these are often the result of the second approach.
Often the result of using the first approach (i.e. minimum changes) is to end up with a slow, complicated unmaintainable mess that doesn’t work properly. In other words the first approach is not always the best approach. Just because you can change something a given way doesn’t mean that you should. The first approach doesn’t always result in a shorter development time either, esp. not when you include the time for support.
So just because you can change a system in a given way, doesn’t mean that you should.
- If you are copying and pasting code, stop and think why?
- If you are adding data access code in a code behind or a MVC controller, stop right there. Whats stopping you creating a class library and moving the data access code at least into it?
Or much better, make a service class library and reduce your controller / code behind code to just a couple of lines. Your code will immediatley start to improve. I don’t care how you then structure your class library, the fact that you have split UI and business / data layers is a major, major win.
- If you have methods that are pages and pages long, either you are coding them wrong, or your database design is wrong, or both.
- Have you got response times longer than 2s on your internal network (WAN access to webservices might be beyond your control)? If so then it may be you are adding everything into a smaller number of views and tables than you should (yes some companies still use Views and Stored Procedures… its ok in my book depending on the circumstance).
There are a couple of things I’m thinking about at the moment:-
- How best to layer software, e.g. user interface (MVC, MVVM), service layer, business logic, data layer, helpers, that kind of thing.
- How best to link different systems together. The old way of using contractors to weld systems together the so called “Best of Breed” approach, falls over when a new version of a system is required. I have refused these kind of contracts for the past ten years or more. The modern way to approaching these kind of integration tasks is to define the interfaces between different systems and using message queing (NServiceBus or RabbitMQ) to handle the interfaces. This has the additional benefit of allowing each system’s individual database design to be under control of the system developers and be changed to meet the needs of that system.
I hope to blog more about this in the future, time allowing.