MUST READ: if you want to be able to maintain and adapt your software to the ever changing world of business and technology.
Explosion of technologies
We’re living in a world exploding with new technologies and programming frameworks every day. Each one of them has advantages and disadvantages, supporters and opponents. The purpose of those new technologies is to try and make our, the coders’, life easier by shortening the time of delivery, by simplifying the accomplishment of typical tasks like creating UI (User Interface), providing CRUD (functions to Create, Retrieve, Update and Delete), ORM (Object-Relational Mapping), or whatever else. Every coder needs to make a decision to concentrate on a set of technologies, understand them, become professional, in a strong belief that they don’t become obsolete too quickly. You simply can’t concentrate on everything, you have to choose…
Example technology set
To summarize, we have this set of technologies as an example of a software project framework components:
- C# (or VB) with dynamic variables, anonymous types and LINQ, version 5.0
- .NET (or Razor)
- MS SQL
Greenfield ? Forget it !
Did you notice that all examples of code found on the Internet, including MSDN documentation, tech blogs, stackoverflow discussions, codeproject portal solutions and so on assume that you are free to create from scratch? Which… is not the case in ca 90% of projects…. Either you end up with a so called brownfield where legacy modules exist or your own software must evolve, because its first version (that was a so called greenfield) is no longer useful and must be adapted to new business processes and opportunities. What happens ?
Take a step back – SRP
Slave of new technology
Number 1 problem
So my number 1 problem in today’s world of software development is that we have too many promising technologies… Technologies and frameworks are still too far from each other, and people using them quickly spread all their knowledge and effort across all technologies thus breaking Single Responsibility Principle. In a strive to stay modern we lose sense of proportion. All these technologies are only tools, and we have to be smart enough to keep following rules that make it easier to maintain quality and fast delivery while using them.
What should I do ?
Well, I need to warn you. All those new technologies are presented in a way that is supposed to encourage new developers to come into the scene and use them. This in turn provides more sold licenses to Microsoft or any other company that offers those technologies, which is fine. But don’t get fooled by all those pretty adverts claiming it is so easy to create applications these days. This simply isn’t the case in real life, in really advanced applications that you are after, my friend. Unless your project is a greenfield (even then it’s only easy with the first version), a program for private use, school activities or one shot simple software. For advanced software that needs to be continuously changed and improved you need plain old object oriented programming and responsibility situated in one place.
- Don’t use SQL procedures nor functions if you don’t have to
Do not put logic in SQL procedures or functions until it’s the only option (for Do not put logic in SQL procedures or functions until it’s the only option (for optimization reasons). Sometimes you need to use SQL’s special capabilities to get a view or report of some kind. SQL is typically better in fast relational joining than C#, which is really slow when doing for/foreach loops. But for a typical CRUD operation you should avoid procedures and functions like a plague. Exception: procedures are ok if they are automatically generated with an ORM framework which makes them adapt if a change in the model occurs. Don’t rely on humans, humans make mistakes.
- ASP/Razor not coherent with C#/ SQL
Same goes for web interface which is very often not 100% in line with ever changing model and business layer. Try to make it transparent to database changes. If you need to change a view (grid, details panel, buttons, etc.) dynamically, don’t code the necessary logic in the view. Do it in a separate class or other part of the business layer. The one where you ask your business objects if some grid column can be visible or not depending on privileges and/or state of an object, whether an action may be presented to the user or not or if some buttons should be clickable or disabled. A view is a view, it should contain no business logic at all or as little of it as possible.
- Dynamic variables/anonymous types traps
Yes, I know there are thousands of other reasons why code can become difficult to change and adapt but my ‘numer 1…’ assumes the readers are advanced developers and/or project/quality managers and follow basic object programming rules.
Other related articles
- Gathering of hidden requirements
- Generics to automate code production, reusability and conventions
- Using Tests in Visual Studio to improve quality
Thanks for reading and regards
CEO, .Net developer, software architect
If you need help with your software project, or need customized software for your company, contact me at: dominik.steinhauf ( at) cys.biz.pl