I hate tools that force you down a particular path, and fight you all the way if you want to do something different than what they want. Every development environment and framework has their own path of least resistance, and various punishments for those that wander from the path. For example, Visual Studio encourages poorly designed applications by making it trivially easy to drop database components onto a web page, wire everything on that page via properties, and just click run. No real-world application should be written like that: it is a maintenance nightmare. Of course, you can write well structured applications in .NET (we do it all the time), but you have to do it around some of the designers and other affordances.
I really like tools that encourage good behavior and punish bad behavior. For example, Subversion is almost perfect for Agile projects because it strongly encourages you to check in early and often. Because it doesn't do any file locking, any file upon which you are working is subject to change by another developer. If you wait too long to check in, you are punished with Merge Hell, where you have to reconcile the differences between the changed file. The easiest way to avoid Merge Hell is to check in very frequently. Statistically, you are much less likely to bump into Merge conflicts.
A framework that encourages good behavior is Ruby on Rails. It builds layered applications by default. In fact, you would have to fight Rails hard to build a highly coupled application. Similarly, if you don't write good unit and functional tests in Rails, you are in great danger of building a very fragile application.
Both Subversion and RoR have the right priorities: reward the Right Thing and punish the Wrong Thing.
Subscribe to:
Post Comments (Atom)
1 comment:
I think there's a very good reason that Subversion and Rails enforce good behaviour (or at least don't encourage bad behaviour).
Subversion was created because CollabNet needed version control features that weren't easily realisable using CVS (which in turn was created to break free of the limitations of RCS). Rails is effectively a by-product of someone with a deep understanding of how to design web applications factoring out all the generic code into a framework.
The common theme here is that these were created and enhanced to meet actual requirements, rather than being written with assumptions about what people will use them for, which is often the case with tools like Visual Studio.
Post a Comment