Friday’s Random Thoughts

Just to wrap up my Austin trip, here’s a few random, slightly organized thoughts on the city of Austin and my trip:

1. There’s lots of good, cheap Tex-Mex food in Austin (but I guess that this is true for most of the southwest).  Damn, I had some of the best Mexican food I’ve had in my life and it was ridiculously cheap.
   
2. PT Cruiser…what an abomination of a car.  If you didn’t know already, the rear window controls are at the base of the center console.  Double-U, Tee, Eff?  I didn’t drive one, personally, but damn, it was ugly, slow, uncomfortable, and the antithesis of ergonomic.  Not that I had it much better; I had a Cavalier.  No wonder the American automakers are tanking so hard…I’m surprised they’ve lasted this long with crap like this.
   
3. The capitol building in Austin has some very nice floorwork and craftsmanship in general.  Very nicely architected and designed.  It’s kind of cool that there’s so much concentrated in such a small area (two universities right around the capitol).
   
   
4. Austin (and probably Texas in general) is very open compared to NJ (the most densely populated state in the country).  I like it.  No traffic jams, wide roads, well designed traffic patterns…I wouldn’t mind living there, to tell the truth.
   
5. TownePlace Suites is so-so.  For $89/night, it was a decent deal as I had my own kitchen, queen size bed, and a nicely sized living room.  The bed was very comfy, but the showerhead was weak and the “light continentel breakfast” really meant “bagel in a plastic bag”.  Homewood Suites, on the other hand, was much better in terms of the food and accomodations (they had a basketball court in the back!).
   
6. Being from the north, I tend to look at people oddly if they’re walking around with a cowboy hat on, which seems to be common practice in the southwest.

All in all, Austin is a very nice place.  Not nearly as congested as most of NJ.

As I had a lot of down time, I made a bit of progress with The Mythical Man Month.  Without writing an entire essay, I’d just like to share some passages that caught my attention.

“Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing great designers upon whom the technical excellence of the products will ultimately depend.”

“My first proposal is that each software organization must determine and procliam that great designers are as important to the success as great managers are, and that they can be expected to be similarly nurtured and rewarded.  Not only salary, but the perquisites of recognition-office size, furnishings, personal technical equipment, travel funds, staff support-must be fully equivalent.”

I’ve never reall understood why so much emphasis was placed on middle management in most organizations.  I do agree that having exceptional managers can help increase organization and productivity dramatically, but the fact of the matter is that there are few exceptional managers.  My coworker, Igor, offered that instead, the emphasis should be placed on teams.  Small, self governing teams organized by technical function (database team, UI team, data objects team, etc).  The benefits of such a system of organization is clear, for no manager overseeing 20-30 employees can truly understand the strengths, weaknesses, and capabilities of each of the employees.  But such quandaries are easily sorted out in a small team where the team must bear the burden of the responsibilities and thus the team becomes accountable for understanding the function and capacity of each of its members.

One point, in particular, that I’d like to share is one of Brooks’ bullet points on how to grow great designers:

“Systematically identify top designers as early as possible.  The best are often not the most experienced. [Emphasis mine].”

Too often in the software industry, the emphasis is placed on years of experience, and not on the actual merits and capabilities of the individual.  As the art and science of software engineering continues to expand and evolve, the best designers will expand their minds and evolve their techniques in parallel.  Software engineering is not a field in which the information and knowledge base remain static.  Certainly, there are core principles that never seem to change, but there are also many different new perspectives, practices, and patterns that emerge with each iteration of tools and environments.  I guess my point is that organizations must find ways to identify and then consequently nuture potential and not merely take the easy road by measuring years of experience.

There were also parts of the text that relate to a project I’m currently working on where the client continually makes change and feature requests, which, by themselves, are not necessarily bad.  But on some levels, the change affects the fundamental design principles of the application, which is time consuming and prone to introduce bugs without massive re-architecting and regression testing.  On this, Brooks says:

“The hardest single part of building a software system is deciding precisely what to build.  No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems.  No other part of the work so cripples the resulting system if done wrong.  No other part is more difficult to rectify later.”

“Therefore, the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements.  For the truth is, the clients do not know what they want.  They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified.  Even the simple answer-‘Make the new software system work like our old manual information processing system’-is in fact too simple.  Clients never want exactly that.”

How true this is.  That last point is particularly interesting.  It’s something that I’ve never understood; shouldn’t the idea be to make it better than what you already have?

As I was driving home, I was thinking about how, I would approach a software design project knowing what I know now.  Sitting in on a hardware infrastrucure design session, it’s clear how different the art of designing hardware solutions is compared to software solutions.  This is not to belittle the work done by the EMC guys, not at all.  But the fact of the matter is that the constraints, requirements, and features are so well defined by the cost and physical limitations of hardware that architecting a hardware infrastructure is a far less torturous exercise than designing a software system architecture.

I’ve been asked before, during interviews, how I approach system design.  I think that the right answer is that there is no answer.  Anyone that dares give “an answer” is like a voter that votes strictly Republican or Democrat, regardless of the particular issues at hand; it’s a foolish and dangerous approach to think that there is one method or methodology that can be applied to every system.

The secret, as I’ve discovered on one of my recent projects that I deem to be my finest work to date, is that software must grow in an almost organic fashion instead of being built.

Of this, Brooks’ says:

“Must of the present-day software acquisition procedures rest upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it.  I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.”

“Let us turn to nature and study complexity in living things, instead of just the dead works of man.  Here we find constructs whose complexities thrill us with awe.  The brain alone is intricate beyond mapping, powerful beyond imagination, rich in diversity, self-protecting, and self-renewing.  The secret is that it is grown, not built.”

“I find that teams can grow much more complex entities in four months than they can build.”

And so it was on my last project; the current (and I shan’t call it final) design grew, piece by piece, line by line, class by class from a conceptual vision that I had in my head.  At every step, I considered where I could refactor the code, where I could make generalizations, where I could consolidate code, and where I could improve the interfaces and classes.  Where I spotted room for improvment, I did so.  With no interference, the very design itself grew as I learned more about the system and the dependent systems.

I can see that many of the practices and ideas behind agile and XP are not entirely new developments, but rather a natural evolution of the ideas that have been present in software engineering for decades.  Perhaps what’s bothersome to me is that, even with this much time, the practice of engineering software is still very immature and it seems as if companies have not learned from the incidents and experience of the past.  We still see an over-emphasis, in many organizations, on management and not enough on discovering, developing, and rewarding top designers and programmers.

Okay, so maybe I’ve run on a little bit longer than I expected 🙂 But I’m done now, I swear!  Enjoy your weekend!