+972 52-548-6969
When does it make sense to reinvent the wheel?
Well, when the wheel is a square, of course:
Adi asks about my seemingly inconsistent behavior regarding when to roll your own, and when to use the stuff that is already there:
What can I say, I have a Pavlovian conditioning with regards to software, I tend to avoid software that cause me pain. Let me quote David Hayden about the CAB and SCSF:
That is quite telling. And I don't think that anyone can say that David is not very well familiar with the CAB/SCSF.
Why do I promote OSS solutions such as NHibernate, Castle?
- Those solutions are (nearly) painless. In fact, they are often elegant and fun to work with. As an example, I worked with a team member today, introducing him to NHibernate Query Generator, he was very happy about it. Talk about painless persistence.
Why did I decide to write my own Mocking Framework instead of using the standard one (at the time)?
- NMock, the mocking framework that I used at the time (2005), was annoying as hell for the agile developer. Bad support for overloads, no way to Lean On The Compiler and No ReSharper. It was a pain to use. I wrote my own, and I like using it. Incidently, it looks like a lot of other people are liking it, but that isn't why I wrote it.
Removing pain points will make you a better developer, period.
Oh, and I do enjoy the discussion, although I wouldn't call it a post war.
Comments
Lets not forget those two aren't mutually exclusive. Open source allows you to change things to work the way you want them to. Igloo navigation...
I don't think annoying as hell is descriptive enough for the pain of nMock. There was a clear need for a better solution... I'd call it an evolution, not a rebuild.
If everyone just used what was already available there would be no evolution of software. There would be no new design patterns, no new frameworks and no new languages.
By using the same argument everyone is using against "reinventing" the wheel one could just as well argue we should be doing all our web development with CGI programs written in C. It worked just fine! Why use anything else?
There really should be only this simple rule when it comes to using an existing framework or rolling your own; Does something that exists currently solve your problem and work for you? If yes, then use it. If not, then roll your own.
And by work, I do not only mean function. A framework only works for you if it does what you need it to do, interacts with the rest of your application in the way you want it to, and is able to be used (coded) in a way you are happy and comfortable with.
Let me just chime in to say I am very glad you didn't just stick with nMock. Rhino Mocks is the best thing to happen to unit testing since... since MbUnit. ;)
Wendy,
I think that I have some posts that describe that way that I went through when I build Rhino Mocks, it was high annoyance with NMock that pushed me to use EasyMock.NET, then the interface for EasyMock.Net really annoyed me, so I refactored that, then I hit some issues related to COM proxies not always being the same thing, so I just rewrote the thing from scratch.
Come to think about, it was the whole process that was annoying, not NMock on its on.
I'm so glad you did Rhino.Mocks!
And Castle just rocks my socks... I've been working on two components to push out to the Castle community. Castle.FlexBridge is a Flex / .Net bridge that actually takes advantage of .Net idioms, handles generics and is open and extensible. (If you've looked at the alternatives you'll understand why I'm doing this.) Castle.Components.Scheduler is a generic job scheduling service. I'm currently providing two implementations, one that supports in-memory job management and another that supports persistence and clustering with SqlServer. (I can't believe I haven't been able to find robust and lightweight components that do the job in .Net.) Unfortunately Quartz.Net is not mature enough to satisfy my requirements and I need this functionality /right now/. I'm hoping I'll be able to plug Quartz.Net in as an alternative scheduler implementation later on.
Oren, are you stealing my post titles. :)
http://intrepidnoodle.com/blog/show/10.aspx
For me it makes sense to reinvent the wheel when the complexity of an existing framework seems too great. However often once fully understanding the problem domain (which tends to come through the act of implementing a new framework) you do occasionally find that some of the complexity is inherent.
When people build stuff for the sake of building without even checking what's out there. It is then reinventing the wheel really isn't well thought through.
Building stuff for the sake of filling an experienced gap or building them as part of your developer training is really a good enough reason for Ayendes Square wheels :P
Although, do that on your spare time. Don't let your customers know that your creating another round wheel from scratch on his bill.
Trackback from
Trackback from http://dotmad.blogspot.com/2007/05/writing-oss-relieves-pain.html
Comment preview