Ease at work - by Kent Beck

This talk given by Kent Beck at Agitar Software offers some great suggestions into being at ease in the work place.

1 of 7
2 of 7
3 of 7
4a of 7
4b of 7
5 of 7
6 of 7
7 of 7

Stress, Neurodegeneration and Individual Differences - by Robert Sapol

Great insight into the various physiological effects of stress.

http://video.google.com/videoplay?docid=1877467554618436978

Tools for Agility - by Kent Beck

The trend toward greater transparency to wider audiences will continue. It may be hard to unlearn habits and beliefs, but in a world of wide and free flowing information, keeping secrets is a position of weakness. You never know when you are going to be found out. Transparency is the new strength.

Tools for Agility

Learning from Lean - by Kent Beck

If software development is lean manufacturing, software
development should aim to produce decisions at the same rate as it
consumes them. If software development is lean product development,
software development should strive to retain and disseminate learning.

Learning from Lean

Promiscuous Pairing and Beginners Mind

Here is a paper by Arlo Belshee that I found interesting:

• http://svn.arlim.org/arlo_papers/Promiscuous%20pairing/Agile%202005/paper.doc

I also saved it locally here:

• http://dougstewart.info/downloads/PromiscuousPairingAndBeginnersMind_ArloBelshee.doc

This form of pair-programming has incredible promise for so many reasons. Hopefully I will encounter an opportunity to practice promiscuous pairing in the near future. The concept of beginner’s mind is something I practice alone, attempting to distrust the auto-solution I’ve learned before in favor of what the problem tells me the solution should probably be today. I trust the problem to communicate far more than myself or anyone else for that matter. I’m probably only about 40% effective by myself though.

I found the paper in a blog post by Steve Freeman:

• http://www.m3p.co.uk/blog/2008/06/15/test-driven-development-a-cognitive-justification/

Composed Method

This pattern is probably my most favorite. The inherent value of small, manageable, legible, understandable, and easily over-ridable methods is perhaps unmatched. How many times has a subclass and a couple of over-ridden methods provided the simple and elegant solution we were after. Or, how many times have we been in the position of having to either copy and paste a “one off” of these methods or completely rewrite the methods, spiking our software stability and test values in the negative direction?

The latter is the position I find myself in most as of late, working on legacy code with no pattern to be found. I attempt to make small improvements and slowly right the ship but the design is so poor that I often feel frustrated and incapable of achieving any real accomplishment through my efforts. I persist however, because I believe in the beauty of this pattern. Testability is of primary concern with this system as it is incomplete, incorrect, and non-repeatable at best. Again I forge through, making the methods smaller, observing the Law of Demeter, using Type Suggesting Parameters, et al.

A system rewrite is in the near future and so my efforts are further daunted by the realization that they don’t matter value-wise as much as I would like to believe they do. I must continue though. I am slowly communicating the brilliance of Kent Beck’s software patterns and even presented a few today.

I love what I’ve learned despite the frustration of my environment. Thanks a bunch Kent.

Smalltalk and Apache

I really want an Apache module that will allow me to script in Smalltalk instead of having to use Php. This would support my goal of making Smalltalk the language of choice and get folks more exposure to life without curly braces (oh and what a grand life it is). With that accomplished, forums, blogs, you name it can be realized through pure OO scripting. Ruby doesn’t quite cut it for me. It’s inconsistent approach to it’s version of “pure OO” makes me nuts. I think this would be the first grand step with lots of little steps in between. If I could somehow incorporate Newspeak into the mix when it becomes available, life may be grand indeed. Beyond that, it will be necessary to engineer application server clusters for scaling applications, and load balancing controllers. I believe in the beauty of this dream, I really really do.

Organic/Evolutionary design

Design up-front is the most established and practiced design discipline in my experience. Most experienced developers/engineers assert that designing system architectures up-front is essential to ensuring that the finished overall application or suite of applications is architecturally sound, stable, inter-operable, extensible, secure, and efficient. The arguments for this design approach are fairly sound and straight-forward. I would argue however, that going this route is detrimental to each of the anticipated attributes listed above. In other words, design up-front ensures instability, quirky interfaces, difficult to extend object models, in-efficient system designs, and hackish end-results. Soundness is a product of all of these and security is a subjective exercise that requires less attention than it normally gets. Assuming that I am correct with this assertion that design up-front is bad for overall system design, what alternative exists that can better it, how does it accomplish this, and what benefits overall can be realized?

Organic or evolutionary software design bucks the trend to figure everything out up front. It follows, in identical fashion, the processes found in nature and in the improvement of all things that are ever built in any field. The idea is simple, build what you need, amend what you need, alter to fit what you need. Every component of new features and enhancements to existing features is based on current AND past needs. Foresight does not come into play. This is an extreme because there are certainly differing levels of foresight that go into building all the mini black boxes that compose a system, but overall, the governing architecture does not exist.

In nature, small incremental changes are introduced. Some of these changes result in no change to the success of the species, other times small improvements are noticeable, and then once every nth thousand iterations, a breakthrough appears that lends considerable advantage to that particular version of the species. The small improvements that lend no real current advantage eventually serve as the basis for this rare breakthrough. The activity that is occurring is called probing; dipping one’s toe in the water to check the temperature before committing oneself to the pool; constructing a prototype to illuminate the merits and detriments of the new design component. The success of mother nature cannot be argued. Evolutionary design is the best design approach available, bar none. Everywhere in the universe, this approach to design may be found. In human terms, our products continue to improve or get worse, but overall the progress is forward. Mother nature and software development learn from probing space and discovering the best form to create or to mutate to.

When developing software, the design up-front approach serves up a pair of hand-cuffs for the duration of the system’s existence, a barrier to becoming what it needs to become. The costs are undeniable to anyone who has ever maintained a legacy system. Business continually presents new needs to us and we continue to hack away solutions to satisfy their requests, never stopping to quantify the costs of not evolving the design three years ago to make adaptation simpler, faster, and more elegant. The costs of barely discernible logic to learn (guess at), modify (break), and enhance (hack) can and do become rediculous and unacceptable. Enter the system re-write in some popular (traditional), established (marketed), and widely used technology like Java or C#.NET.

Why is the rewrite necessary? Because the system never became what it needed to during it’s development. Instead, while the system worked, it became too difficult to amend, too expensive to improve, and too far behind current best practices, frameworks, protocols, and the like.

Test Driven Development, Test First Development, Prototyping, White-board Discussions, et al., are all probing activities that enable us to incrementally evolve our object designs to fit the current picture of the system. The activities we must employ to achieve success with this design paradigm include refactoring, spikes (prototyping), drawing pictures, carding sessions, and many more. The idea is to slowly discover the best design approach today, always understanding that contexts and requirements will alter that design going forward, in incremental fashion. The blockades of cost up-front must be removed. A case for this design approach must be communicated to the business as an eventual cost savings.

There are many benefits that naturally emit from such practices:

• happier developers
• better stability
• better interoperability
• better security
• easier to test systems
• looser couplings
• better adaptability
• better extensibility
• less code
• lower overall system cost
• et al

It’s not easy to convince most folks about this approach but I guarantee that following organic design practices will leave traditional design up-front systems far far behind.

A couple of organizational suggestions:

• Remove the position of programmer and architect. Everyone is titled as some level of engineer and each engineer is held responsible for the overall system architecture. Teach all developers how to incorporate good design practices, insist on good coding standards (including one style guid). Replace engineers who are unwilling to buy-in to this approach with engineers who are fully on-board (show some courage and make the best system you can).
• Practice pair-programming at least 50% of the time, to the extent that is possible. Cross-fertilize the organization with knowledge, ideas, approaches.
• Extend the evolutionary design principles to everything your business does, including improving or replacing tools, practices, and people.
• Trust your engineers and give them the opportunity to save you lots of money on down the line (let them refactor, insist upon it)
• Drive your development with tests. Make all your objects testable. Every object has a minimum of one test case with tests that exercise 100% of the class’s methods.
• Use Smalltalk, focus on business solutions, not syntax, typing, memory management, and performance. I find it interesting that (in my exposure) every C program needs memory management attention, every Java application needs performance attention, and every Smalltalk application “Just Works, and works fast”. Show me different, I suspect it doesn’t exist.

Style/Formatting: Vol 1

Style or formatting is the most ignored practice in all of programming - well, arguably. To me, formatting represents the single most important part of the coding. Formatting has the potential to do the following to the code:

• enhance the understandability of the code
• make the code easier to read
• reduce the amount of time a developer spends deciphering what the author intended
• encourage good programming practices
• speed up the development cycle
• illuminate stinky code, cheats, shortcuts, hacks, you name it
• reduce the learning curve for new developers
• lend a consistent pattern to all methods
• uncover hidden code complexity

One of the problems with style is choosing one that everyone will agree on as the best. Another problem is getting everyone to adopt the style that is chosen. Finally, getting everyone to consistently repeat the style and not do it only some of the time.

With smalltalk, I’ve seen many different styles, usually an amalgamation of several different authors with different styles that achieve different purposes. I’ve only found one style that encompasses a holistic approach to software design and patterns; only one that achieves all of the bullets above and a few benefits I’ve forgotten. That is the one proposed by Kent Beck in his book Smalltalk Best Practice Patterns in Chapter 7. The styles he presents are so common sense, I can hardly believe that not one of the smalltalk distributions have adopted it. With so many smart people, why can they not see the genius in this style guide.

I just don’t understand why style is ignored to the extent that it is. Code is more important than good code unfortunately and I guess that is the main reason why. I can understand each shop wanting to employ a style of their choice, but shouldn’t the baseline formatting be the best that is available. I welcome a debate on which style guide is best. Some will win in small scenarios but nothing that I have seen or read about touches the brilliant guide that Kent Beck put together. I may opt to adjust a few things in his guide, but nothing very big, and nothing I simply “have to have”.

So, what makes a good style guide anyway? I believe that it begins with the phrase, “no exceptions”. In other words, very very consistent. Another measurement is in regard to readability. If the code formatting itself can relate to me the flow of the code, I can read it much better.

Consistent is a bit ambiguous when discussing code styling because one must consider indents, contexts, and other punctuation and syntax. The most consistent will cause all the rules in the style guide to always be true.

Here’s a little example, in Smalltalk, of course:

^1 = 1 ifTrue: [1] ifFalse: [0]

Now, after applying Kent Beck’s style guide:

^1 = 1
   ifTrue: [1]
   ifFalse: [0]

While the first example is more concise, and I know a bunch of programmers love concise code, the rule is that whenever the receiver is sent a multi-named method, it’s components drop down to the next line.

The readability of the code may not seem much different in this example, but trust me, legacy systems can include some herculean methods and following them is next to impossible without Kent’s formatting. And, that is the point. Using this style guide works for all cases, bar none.

Here’s a slightly more complex example:

[one=1] whileFalse: [one:=self getOneForDate: Date today withId: 3.
one=9 ifTrue: [ self displayNine] ]

I agree, the above method isn’t terribly good, but its only purpose is to illustrate how styling can improve readability. Here it is again, formatted according to Kent’s style guide:

[one = 1] whileFalse:
    [one := self
        getOneForDate: Date today
        withId: 3.
    one = 9 ifTrue: [self displayNine]]

I will talk more about each of the style rules in more detail in subsequent posts. I only wanted to introduce the topic here to get me started.

The second example is far easier to follow and gives us little to decipher. Instead, the code just speaks to us because we expect it in a certain form and it is always in that form. There’s little guessing about how this little bit of code operates, horrible as it is.
Let me add an ifFalse: to that last part and see how it changes:

[one = 1] whileFalse:
    [one := self
        getOneForDate: Date today
        withId: 3.
    one = 9
        ifTrue: [self displayNine]
        ifFalse: [self displayEight]]

In essence, whenever a chunk of code takes up more than one line, it begins on the next line. Multi-named methods constitute more than one line.

So, that’s a start. Styling can reshape the way we view solving problems, it can reshape our thinking so that the language doesn’t entirely exist. Instead, Smalltalk becomes a kind of blur in the background as we design elegant and patterned applications and spend most of our time testing and refactoring.

Movie Reaction: Instinct

Brief Summary: Anthony Hopkins plays a biologist who has studied apes for many years. He ends up in a security hospital/jail for folks with mental issues. He is then confronted by Cuba Gooding Jr., a psychologist who implores Hopkins to tell his story.

Reaction: Just watched this movie for the second time over the weekend. I was so moved by the forged relationship between Hopkin’s character and the small clan of apes who had accepted him as one of their own. The movie reaffirmed to me the beauty in all creatures and how we humans continue to ruin our world with consistent disregard for our true place in it.

While we should be the caretakers, we instead take care of only ourselves. We continually find ways to place ourselves in a position of superiority and disregard all the “lesser” life-forms. We find ways to divide ourselves and our world, we forget that we are a product of this world and should hold all things in the deepest respect.

This movie made me want to divorce the human race altogether. Why do we place so much value in inanimate objects (money,  cars, houses) and focus so much negative energy on ourselves and each other? Why are we not practicing advancing our world and instead continue to destroy it?

I found many meanings in this film for myself. It touched an inner part of me that had been lying dormant for several years now. I’ve avoided the animal channel because I did not want to face the realities of what is happening with our Polor Bears, our pets, etc… It is truly painful to bear witness to the suffering that we humans inflict on the rest of the animal and plant species. I realize, however, that the pain is a gift and a communication to pay attention and to act in whatever capacity I have available. To contribute what I know and wish for and to assist and aid with reparations.

I highly recommend this film. Who knows, it may touch some part of you as well.