This post originated from an RSS feed registered with Java Buzz
by Chuck Hinson.
Original Post: The Windows Way vs the Unix Way
Feed Title: Chuck Hinson
Feed URL: http://chuckhinson.blogspot.com/atom.xml
Feed Description: Observations, questions and musings related to my life in the software industry.
A colleague comparing VCS systems commented that while TFS includes pretty good bug and issue tracking components, systems like Git and Mercurial have to to be combined with Trac or Bugzilla to get the same set of functionality. As I was reading his comments, it struck me that this was another great example of the Windows Way vs the Unix Way.
The Unix way is to have lots of small focused tools that do one thing well and that can be plugged together in any combination that meets your particular needs. Often, there are multiple tools that do approximately the same thing, but in slightly different ways, each convenient to a particular set of needs. This leads to highly tuned solutions - you can pick exactly the right set of tools that both solve your problem and fit best with your environment. The down-side to this is that you need to be skilled in knowing how to fit the right pieces together. Knowing which tools are best suited to your environment takes a good bit of experience - but once you have a solution, it fits like a glove.
The Windows way is pretty much the opposite. The Windows Way is to construct a single monolithic piece of software that solves a whole general class of problems. The great thing about this approach is that there's no assembly required. You dont need to know about lots of different tools and how to make them all work together - you just need to know that one tool. And because you only need to know one, you can get to be pretty knowledgeable about it. The downside to this, of course, is that while general solutions can usually do a lot of things, they often do none of them well. General purpose solutions have to make assumptions about the context is which they will be used, and if you deviate from those assumptions, the solution doesn't operate as efficiently as it could.
So is one better than the other? Not really. At least not without having more context. Sometimes a general purpose solution is sufficient. Other times, you need the flexibility to be able to create a highly specific solution. The trick is to know when each is appropriate.
Previous Topic
