Statement Refactoring

I've just noticed this somewhere:

public string MakeRequest(string hostname, string message)
{
    Socket socket = null;
    IPAddress serverAddress = null;
    IPEndPoint serverEndPoint = null;  
    byte[] sendBytes = null, bytesReceived = null;
    int bytesReceivedSize = -1, readSize = 4096;
    serverAddress = Dns.Resolve(hostname).AddressList[0];
    serverEndPoint = new IPEndPoint(serverAddress, 80);
    socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);
    bytesReceived = new byte[readSize];  
    sendBytes = Encoding.ASCII.GetBytes(message);
    socket.Connect(serverEndPoint); 
    socket.Send(sendBytes);
    bytesReceivedSize = socket.Receive(bytesReceived, readSize, 0);
    socket.Close();
    if(-1 != bytesReceivedSize)
    {
        return Encoding.ASCII.GetString(bytesReceived, 0, bytesReceivedSize);
    }
    return "";
}

Why do programmers still write code like this in C#? Do they like verbosity? Why not write this instead:

public string MakeRequest(string hostname, string message)
{
    IPAddress serverAddress = Dns.Resolve(hostname).AddressList[0];
    IPEndPoint serverEndPoint = new IPEndPoint(serverAddress, 80);
    Socket socket = new Socket(AddressFamily.InterNetwork,
                               SocketType.Stream, ProtocolType.Tcp);
    int readSize = 4096;
    byte[] bytesReceived = new byte[readSize];  
    byte[] sendBytes = Encoding.ASCII.GetBytes(message);
    ...
}

It seems to me there are loads of these statement level refactorings that would prove really useful. Do any tools support "small" refactoring like this? Do any books talk about them?

Here's another: Instead of writing:

if (expression)
    return true;
else
    return false;

why not just write:

return expression;

How Buildings Learn

I've been rereading How Buildings Learn by Stewart Brand. It's a really great read. It's author took the time and effort to do what few authors do. He didn't do the simple thing and just write about buildings at a certain point in time. He did the difficult thing and wrote about the underlying processes that govern the evolution of buildings over time.

At the heart of this book is the idea of change - of time. That buildings change. That people change them. That the elements change them. This, fundamentally, is the reason the parallels with software leap off every page. Understanding and managing change is arguably the fundamental aspect of understanding and managing the process of developing software. Software isn't written perfectly in a sudden flash. It takes time. It takes lots of small changes. The author writes "My approach is to examine buildings as a whole - not just whole in space, but whole in time". He laments the aphorism "Form ever follows function" written in 1896 by Louis Sullivan (A Chicago highrise designer) because "it misled a century of architects into believing that they could really anticipate function". The idea is to aim for software that gets better over time. Or, more accurately, that is capable of getting better over time.

Here are some quotes:

Our basic argument is that there isn't such a thing as a building. A building properly conceived is several layers of longevity of built components.

Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.

Hummingbirds and flowers are quick, redwood trees slow, and whole redwood forests even slower. Most interaction is within the same pace level.

The dynamics of the system will be dominated by the slow components. with the rapid components simply following along. Slow constrains quick; slow controls quick.

Trust, intimacy, intense use, and time are what made these buildings work so well.

Architects offered themselves as providers of instant solutions, and only the look of a building gives instant gratification.