Helping everyday developers succeed
Software development is hard. You have to know how to use so many different tools and you have to try and keep up with it all.
Lately I’ve been hearing some griping about certain tools that people feel are trading good software design principles for ease of use. Many of these tools usually have some kind of drag-and-drop designer functionality that is designed to help you get things done faster. The griping comes from the fact that these tools can cause developers to make poor design decisions because the drag-and-drop tool led them in the wrong direction. I can’t say that I disagree with these complaints.
There are two sides of every coin, so let’s swing the pendulum the other way. Many open source libraries that I’ve seen take a different approach to design and the people that write them say that they’re not writing them for the novice user and that you will have to be familiar with advanced design patterns in order to use these tools. I think this is a good thing because software development is complicated and it’s OK to have make a library more complicated so that it fits in with good design patterns (like the need for an IoC container in FubuMVC).
Sometimes I wonder if we could do more to make these complicated tools easier to use. Take ORMs for example. Most people out there would agree that NHibernate is the most fully-functional ORM that we have. Yet I was on a project a couple years ago where developers floundered around trying to get their NHibernate mapping files to work (usually because of stupid stuff like typos, not making the .hbm.xml files Embedded Resources, not fully qualifying an assembly name, not making something virtual, etc.). Eventually we got better at it and we learned the tricks, but we wasted a ton of time trying to fix stupid mapping file issues.
For the next project I was on, we chose LINQ to SQL over NHibernate (this was in early 2008 when LINQ to SQL had just come out). I had an existing database with my tables in it, so I dragged them all into the LINQ to SQL designer and started writing business logic. It was amazing! It all just worked!
Now that led me into other pitfalls because now I had to map my objects 1:1 with my database tables, and crap from the database concerns cluttered up my model and caused a lot of grief. But even with that, we got work done much faster with LINQ to SQL than with NHibernate. Does this mean that LINQ to SQL is “better” than NHibernate? I wouldn’t say that, yet I was able to be more successful with LINQ to SQL. This is an important thing to note.
Open source tools like NHibernate are usually written by really smart people. Really smart people have no trouble figuring out complicated stuff. Sure, they may experience the same pain at first, but they pick it up quickly. All of the other really smart people that they talk to understand it too.
Not everyone is really really smart, unfortunately. I hear a lot of people harp on NHibernate and say it’s way too hard to use, that it’s not worth it, that there has to be a better way, etc. Most of these opinions come from a bad experience that they had with NHibernate.
I can’t discount these opinions that people may have. While these same people may agree that NHibernate is the most fully-featured ORM out there, for them it is not the ORM that will make them the most successful. I know a lot of people in this camp and they are not stupid people and they aren’t too lazy to learn NHibernate. It’s just that NHibernate did not lead them into the pit of success.
The fact is that most developers that are going to be using tools like NHibernate are your common, average, everyday developer — not bad developers by any stretch of the imagination, but they’re not as smart as the really smart people. I’m certainly not saying that we should sacrifice functionality and good design patterns to make things easier to use. I just think that more effort should be spent on making sure that average developers can figure out how to use something correctly, whether through documentation, good examples, or coming up with easier ways to do things. Really smart people don’t need these things to be successful with these tools, but the average developer will benefit immensely.
For me, this is what Fluent NHibernate did for NHibernate – it abstracted away a lot of what was difficult about NHibernate. Recently I’ve been able to use it on a project and it totally turned the tables. Now I get the power of NHibernate but I can use conventions to auto-wire my mappings, and the mappings are all in code instead of in XML. For me this is a huge deal. Now I get the power of NHibernate and I’m not stuck doing all of the crap that slowed me down before.
Another example of this is the reams and reams of documentation that the Microsoft patterns & practices team has written up for writing secure applications with WCF. WCF is very complex and powerful, but Microsoft did not leave us hanging and wrote up what to do in almost every scenario imaginable. They didn’t just give us a tool, they gave us what we needed to be successful with it.
We need more stuff like this.
Well, you know my opinion on ORMs. As a database designer, it infuriates me when I see design quality being compromised in order to accommodate development tools.
blindman,
It’s all about time and money. ORM saves time and money. If you want to write every DB transaction as tuned custom stored procs, you can do that – and the customer will pay a ton of extra cash for it. You also end up with an application that is difficult to maintain for the average .net application developer. MS.Net Applications, without using ORM, are pretty fat by themselves. Look at the DataTable and DataSet – they force a double loop through result sets, and they hog memory to boot. However, they make the development process a ton easier – just like ORM does.
This whole idea of quality being the top priority for business applications in the real world is ridiculous. I mean, what would happen if you take it a step farther and write components in C++ or C and assembly? You end up with a kick ass super fast application that costs a ton to build and maintain. That just doesn’t work into most budgets & time lines. It sucks for those of us that are obsessed with writing efficient code, but that’s just the way it is.
I think one of the reasons why .net/java applications are so poorly written these days is because the community is flooded with “certified” developers that don’t have a good background in computer science. I have little respect for developers that have no experience in C++, C and Assembly (and in the web world, HTTP, HTML, and Javascript) – with very few exceptions. Many of the ASP.Net programmers I’ve met had no idea how HTTP worked. They were blown away when I showed them an HTTP sniffer and explained the difference between and POST and a GET. Unbelievable. They have a low bill rate, and that’s all that matters. I’m going to get off my soapbox now. ;)
@Justin,
I agree with you, certainly there is a trade-off between quality and efficiency vs. ease of use and maintainability.
Jon
Hello!
Very Interesting post! Thank you for such interesting resource!
PS: Sorry for my bad english, I’v just started to learn this language ;)
See you!
Your, Raiul Baztepo