Object Thinking

I recently finished reading…

As usual I fold down pages that contain paragraphs that interest me… below are a few excerpts from the book that I enjoyed!

“Better people” has been recognized as the most promising silver bullet for addressing the software crisis, and yet almost all of our energy has been spent on creating better tools, methods, and processes instead of better people?

Imagine what a team of “better people” can accomplish. Now stop imaging, and start investing in fostering cultures that cultivate “better people” all working towards the same goal.

An unspoken but just as widely held belief that really good developers were not to be trusted – they could not be “managed”, they all seemed to be “flaky” to some degree, and they did not exhibit the loyalty to company and paycheck of “normal” employees. Really “good” developers tended to be “artists”, and are was (is) not a good word in the context of software development.

Those flaky artist types… *sigh* It’s important to allow individuals do what they are good at, that’s obviously something they like to do. It breeds innovation, and efficiency. When working in a team it’s important to be respectful of one another’s opinions and work together.

Every once in a while someone on the team will have a crazy idea that just might slash the complexity of the whole system. If they have courage, they’ll try it out. It will work (sometimes).

It’s important to have courage on any team. XP teams value courage. Without the courage to grow and challenge one another, your team will remain stagnant. By challenging one another you’re showing one another respect by saying that “I want you to get better, and I expect you to want me to get better as well”!

Object thinking is a “crazy idea” capable of increasing simplicity in software design – crazy in the sense that it does not conform to traditional thinking about software development, crazy in the sense that it revolts against the computer thinking employed by most software developers, and crazy in many of the same ways that XP is crazy.

Trying to introduce object’s into a culture that’s firmly devoted to thinking in terms of data can seem like a crazy idea too. There is a time and place for everything, I’m sure objects aren’t great for every system. A little bit of object “thinking” can help though, I’m sure.

As a formalist, the computer scientist expects order and logic. The “goodness” of a program is directly proportional to the degree to which it can be formally described and formally manipulated. Proof – as in mathematical or logical proof – of correctness for a piece of software is an ultimate objective. All that is bad in software arises from deviations from formal descriptions that use precisely defined tokens and syntactic rules. Art has no place in a program. In fact, many formalists would take the extreme position: there is no such thing as art; art is nothing more than a formalism that has yet to be discovered and explicated.

Art is something that I enjoy. One of the reasons that I was drawn to software was the creative aspects of it. I first thought of developing software as a form of art. It’s great how Test Driven Development allows you to prove the correctness of a piece of software, but also enables you to refactor and be creative.

An analogy to chess playing might illuminate the relationships among method categories. A beginning chess player follows rules and defined procedures (they are formalists), while a journeyman (informalist) relies on patterns and heuristics. A grandmaster has internalized and transcended the informal to become an aformal player.

I’m currently reading a book on NLP, and it describes how experts do most of their work subconsciously, instead of consciously. It’s like when you learn to drive a car (assuming you learned on a manual transmission). First you have a set of steps that you must follow, and repeat. Then you begin to follow patterns. (I used to look at my current speed to decide whether to shift gears.) Then you stop thinking about it, and you just drive.

A human uses mechanical weights and machines in a gym to increase his innate capabilities – to make his own muscles strong and more reliable. Using a more cerebral metaphor (and one therefore more appropriate for object thinking), Kent Beck suggest using method and even XP practices as if they were etudes (musical exercises designed to help the musician internalize certain skills and techniques.)

Time and Focus equates to discipline, according to me.  In order to excel at something you need to invest both time and focus to truly excel at it. There really is no secret to getting better.

A common tendency for new object developers is to list as responsibilities things that an object must “know.” An airplane must “know its current location.” While this may be true, it can be misleading. It implies too much about how the object might be implemented because “knows” implies an instance variable. It’s also quite possible that an object will know things (a private key for decryption, perhaps) that it will not be willing to share with others and that therefore will not be included in the interface for that object. Provide private key would not appear as a service, although the message privateKey might be in the object’s protocol with the designation that it is a private message. Decrypt message, on the other hand, might be a listed responsibility. Always state your responsibilities in terms of a service, with an awareness of a possible client for that service.

I know when I first started transitioning from procedural to object oriented programming, I thought mostly about where and how the data was going to stored, and how to get the data. “This auditor class needs to have a sorted list of audits”… Now it’s a little more like “An auditor can submit an audit of a company to …”

This was a great read for anyone wanting to get into objects, or learn more about the history of objects. It was great to read about were a lot of present day ideas originated from.