While on the subject of frameworks, think about this. I used to work in Java, and found that my choice of frameworks and technologies was staggering. I had EJBs, Hibernate, Spring you name it, I could use it.
But this I actually found quite daunting. How am I supposed to choose between them? When I made the move to .NET, I found that actually, the Micro$oft monopoly helped me out a bit. Suddenly there was an objective statement: “This is how we expect you to develop software using our tools”. These methodologies were built right into the IDE, ready and waiting.
With The Antitrust Case, building IE into Windows was a good move and a bad one for Microsoft. It got them mass exposure, and IE became the default web browser for the masses. They built their own tools right into the OS, thus making the OS more functionally rich out of the box. This meant that the average new computer user would never have to look past the end of their nose for most things. It was only when the competition realised how difficult it was to get people to make the switch that this began to change.
So with that in mind, surely we should be thinking that the prescription approach is a bad one – after all, it’s hard to argue that NHibernate doesn’t beat the built-in DataSet designer hands-down, but in terms of the all important usability stakes, the DataSet designer takes the chequered flag.
So, another case of wrong is better? It certainly buys time to work out your version 2 with the fancy NHibernate database-independant data access layer, but to get your version 1.0… Well, let me know what you think.
What’s your opinion on pre and post build steps? Personally I prefer all my build operations to be performed by the build script itself, so that if there are any problems to be fixed or changes to be made, I only have one place to look and one thing to update. Post-build options are what you look at hours into a problem when you finally remember that you have them, so can make debugging your build process much more difficult.
Let me know what you think.
Or a blog post? Should we be optimising not just our web applications, but our content, to be more digestible on the latest PDAs/iPhones/Feed readers? I’d like to post more images on this blog, but since it’s hard to find images relevant to the text, I prefer to leave them out rather than clog up my readers’ bandwidth with irrelevant content
How do you go about self-editing on your blog? Do you say what you want, or read it over and over until it’s as finely optimised as that Towers of Hanoi application you created at college?
Frameworks are all very well – we’ve got our pick of Hibernate, EJBs, etc, plus all the .NET ports (and that’s only data access, think about the Microsoft Application Blocks), but have you, like me, come to the conclusion that the learning curve for some of these is actually a little steep?
How do you find out whether one of these choices is the right one without going through the whole learning curve, and at what point does “rolling your own” become a viable solution again? It’ll do exactly what you want, the way you want it to. You’ll find it easier to maintain, and when you need a new feature – you add it. The overhead of writing it in the first place could be offset by the overhead of learning a framework – but you know for certain that it’ll do what you need when you’ve finished.
Of course that’s kind’ve what open source should do. You could always contribute to NHibernate, but you just make the learning curve steeper, because you have to learn how to change it as well as how to use it. People may like your work, and it’s always nice to contribute, but that won’t get the project you’re working on done any quicker, so your boss might not be so happy.
Now, I’m all for avoiding writing boilerplate code, but even these days I’d definately still consider writing my own data access layer, and maybe even (dare I say it) a code generator to go with it. The days of re-inventing the wheel aren’t over, and maybe that’s a good thing, as Dave Winer and Fred Wilson both agree, just spitting out the same-old, same-old could even be bad for business…