At the risk of procrastinating other work and becoming a chronic poster, I’m going to go for a second one today.
Following on from my previous post discussing the merits and woes of particular IDEs, an overriding theme which runs through my dislike of the .NET framework is the fact that it is a framework. Taking the literal meaning of the word framework – I can explain my issue with the things quite easily. You see a framework in its true sense is like scaffolding – it is used to hold something up and to keep it together. The trouble is you take the framework away and you are left with something that doesn’t hang together properly. I’m not the only one with this concern about a framework development pattern, plenty of developers share it. Aside from the difficulty of integration with things external to a framework based development environment – it’s hard not to fall into the trap of developing frameworks for your own use. The convenient few classes you have used repeatedly to help you out can grow out of control into something that is horrendous to maintain.
The alternative to framework based development is to ensure as much modularity as possible, which requires thinking about how your programs and classes may be used from another developer’s points of view. The more your code can function autonomously, the easier it will be to maintain.
One of the big problems to avoid when programming is making a whole ‘toolset’ which can only be used on its own. You wouldn’t design a screwdriver that can only be used in combination with a drill and spanner at the same time, so why program like that?
