RE: Unix philosophy under the gun?

[Ralph Mack]

> From: "Thornley, David" <address@hidden>

> While I understand deadlines and the extreme importance in 
> some cases of time-to-market, headlong coding is not a very 
> reliable way to construct quality software, and some attention 
> to fundamentals is usually better in terms of quality and in 
> terms of time. 

I absolutely agree. It is important to know what the requirements 
are and are not, to understand the tasks they entail, to design 
the solution system so that it is comprehensible, to implement it
so that it is continually tested and to empower the team members
to change any part of the software. For me, that means good user 
stories, customer involvement, iterative test-first development, 
pair programming, refactoring, etc. 

However, all of these tasks have one thing in common: a total and 
exclusive focus on the problem to be solved and the code of the 
system that solves it. I have seen so many companies fold because
they built an inappropriately large infrastructure to support their
operations. Winners can't afford big design a la RUP or big version
control a la ClearCase or big IT or big MIS or big management. 

I want a set of tools that permits developers to get the job done 
without really noticing the tools themselves. Using software tools 
should be like reading - if you are aware of the words that are 
being used or the paper they are written on, you aren't absorbed 
enough in the story. Likewise, a window is invisible because you 
see what you are looking at through the window and, unless it is 
dirty, it doesn't get in your way, demanding your attention. 
Tools should be like clean windows.

> Creating software is a bit more complex than butchering hogs, and 
> it is usually desirable to have some specialization of function.  

Creating software is complex because of the complexities of the 
trade-offs in what we're creating - using the tools to create it 
shouldn't be. I also respectfully disagree about specialization 
within the software development function - to truly have collective 
code ownership you need to prevent specialization by pairing for 
knowledge transfer and rotating work assignments through the 
different areas. 

> The checkout/commit/update is enough to be productive with 
> CVS if you don't use branches.  If you do, then somebody 
> can create a script to automate merging in a way that is 
> useful for your organization.  

There is no reason that using branches needs to be complex in
order to be effective. Tracking past merges makes it possible 
to perform any desired merge optimally; this should be a basic 
characteristic of the merge function. It eliminates the need 
for organizations to maintain merge scripts (or, worse yet, 
lists of things to look up and commands to type) to use merges 
at all but in no way dictates policy. 

Ralph