Practices of an Agile Developer

I just finished reading "Practices of an Agile Developer". It's filled with tons of practical advice. I think it should have been called "Practices of a Good Developer. Period.", but I doesn't have the nice sexy ring to it. It's extremely short and they touch on the topics. It's great if you don't have a lot of time on your hands. I still recommend "Code Complete 2" for more coverage on good practices. But, I loved the "how to work with people" aspect of it which is unusual in technical books, but common in manager texts. The devil/angel quotes were cute and entertaining. It's certainly not a dull moment with lots of excellent analogies (common for the pragmatic programmer series). Anyway, I recommend it and it doesn't take long to read at all.

Back To Opera

I downloaded the lastest Opera today. I left Opera a year ago because Firefox held so much promise. Well, I liked the thoughts behind Firefox (Javascript coding with GreaseMonkey, Plug-ins, etc), but I have decided to return to Opera. It's faster. The interface is better planned and it just fits the way I browse the web. Oh, did I mention it was faster and doesn't hog the CPU at weird times? Opera is love. I am going to miss Sage though.

What A Compliment!

Brent Adkisson just started his blog and gave me a compliment. Perhaps one of the best that I've ever heard. It'll be one of those that I stash away for those rainy negative days.

If you know Blaine you have had a glimpse of one of the best coding minds I have ever had the pleasure to meet.

Wow! Brent is too kind. I don't think I would go that far...I'm still a journeyman in my mind. Brent is a great guy. Always laughing and smiling and never ceases to put me in a good mood. Oh, and did I mention, he's a kick ass coder as well?! I only keep the best company (so I always plenty of brains to learn from).

Iterable and for

I love the fact that there's a new interface in java.util: Iterable. Why you might ask? Could it be for the new shorthand for?

List someList = ... ;
for (SomethingCool each : someList) {
   ...
}

Well, that would be one reason to get excited. Close, but no cigar, no, I like the fact that the method iterator() has been split from java.util.Collection. It allows one to have infinite collections. Most of the time, you don't care how large the collection is, you just want to traverse over its elements. Iterable allows you to do just that. All you care about is that it can produce elements. This means if you have a large file, you could read it in chunks without anyone being the wiser. They would just have an Iterable object and not know how things worked in the back end. Encapsulation at its finest.

  String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader) {
    ...do something cool with each record...
  }
  class RecordReader implements Iterable {
    ...
  }

The client of RecordReader knows nothing about how many records are read in from the file at once nor should they care. They just want each record. We could for example read in 500 records in at a time or just one. It doesn't matter. We could even pass how many to read in at once as an argument to on. Throttling is left to us as a performance enhancement in one class.

Iterables allow us to have true object streams. How cool is that! For giggles, we could have also implemented it totally differently. This time I return an Iterable when asked instead of making the RecordReader implement it. I like this approach much better.

String insanelyLargeFileName=...;
  RecordReader reader=RecordReader.on(insanelyLargeFileName);
  for (Record each : reader.records()) {
    ...do something cool with each record...
  }
  class RecordReader{
    ...
    public Iterable records() {
      ...
    }
  }

The naive (or simplest) implementation of records() could simply return the entire collection of the file using an ArrayList. And when the file got too big, then move to a custom Iterable object that could read in chunks of the file. By putting iterator() into its own interface, we got a greater flexibility beyond the nice new for sugar. Polymorphism is a wonderful thing wouldn't you agree?

I use Iterables all over the place in my Reflective Testing Framework to traverse over classes, class path items, and methods. It allowed me to have a nice pipes and filters pattern throughout the code. It also made it easy for others to extend what I have done. Have fun! Iterable might be the best new feature of Java5.

Talk Went Great!

Matt Payne had great things to say about my talk:

"a Java 5 tour de force presentation that was backed up with a whole bunch of fantastic BSD licensed code"

WOW! You can't ask for a better compliment than that! Harish Keshwani had good things to say as well.

The thing that shocked me the most was how well my talk and Matt Secoske's on Performance fit so well together. We discussed our presentations before the meeting, but didn't plan on them being such a one-two punch! It was very cool.

I can't wait to expand the code that I have. ROCK!

Automated Standards Enforcement

In celebration of my talk tomorrow night, I have started a page on Automated Standards Enforcement. There's not a lot of content there yet. But, I plan on adding plenty of examples and more resources. Right now, I link to a bunch of books, articles, and my two frameworks. One is written for Squeak and the other Java 5. Both have source and tests available. I'm going to try to have the Java presentation up soon. My talk from Smalltalk Solutions is already there. Enjoy!

Right On

Mike Bowler said:

The majority of programmers fall into the non-expert category. They can see the differences between some of the less powerful languages like Visual Basic or Java™. They do not, however, understand how much more powerful some languages are.

You have to have a deeper understanding of languages to be able to compare them effectively. If you don't understand closures or continuations, for example, then you won't understand why languages that support them are more powerful than languages that don't. If you don't have a good grasp on the idea of self modifying code then you have no hope of understanding why lisp macros are so incredibly powerful.

Someone who only knows languages like Java™ or Visual Basic or C#, will not be able to appreciate why Smalltalk (or Ruby, or Lisp, or ...) is a more powerful language than what they already know.

Right on!

Four is The Perfect Team Size

The most successful teams that I have been have all been small. In fact, I've long believed that four was the perfect team size (three the minimum, and five the max). Of course, this was simply a gut instinct. It has been experience. I never thought to look up an research on the matter.

I was talking with my co-workers today and about fell over myself when one of the mentioned that the optiomal team size was three to five. I asked him why he felt this and he said, "Well, I found some research that says so." The look on my face must have been priceless. Eagerly, I asked him to give me the papers. He kindly told me to google "Optimal Team Size". I asked him what made him look it up and he replied, "I wanted to know the optimal group size for role playing games."

Here are the best articles that I found. Enjoy reading! All of it gave me lots of information to chew on.

The most telling quote was one by Steve McConnell. He not only advocates a small team, but relates what we've always known: code quality is dependent on the qaulity of the programmer. Methodology plays a little role in all of that. It's all about the people. Check it out:

According to Capers Jones's "Program Quality and Programmer Productivity" (IBM Technical Report TR 02.764, Jan. 1977), on small projects, construction errors make up about 75% of all errors found. Methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the program.

On typical larger projects, construction errors taper off to about 50% of total errors, while requirements and architecture errors make up the difference. Presumably, this is related to the fact that proportionately more time is spent in requirements development and architecture on large projects, so the opportunity for mistakes in those activities is proportionately larger.

I thought it was cool that there was research out there to prove my gut instincts.

Lead Vs. Follow

It is written that a great leader is not only good at leading, but following too. The same rule can be applied to coders. Sometimes you take the lead over a design when you feel the passion and other times you let someone else take the reigns. The important thing is not to feel the need to always be the one in charge. Let others lead.

Following does not mean to blindly go over the cliff, but to question and suggest. Realize that the person leading has the final decision. Without a clear leader, tug of wars result in code decay of the worst kind. Trust your team partner, but make sure your communication is clear when you disagree.

Too many times developers get into the mindset of always wanting to be the lead dog. Resist the urge. Learn to standback, do things differently, and most importantly grow and learn from doing a design differently. You will also gain the respect and admiration of your team. If you want people to support you, you must support them too.

When Is Too Complex, Too Complex?

This Java Generics FAQ is a whopping 433 pages in PDF form. Holy Moses! I went to print it out at work and was shocked by the size. The special cases are simply amazing. There's things that I hadn't even thought about it. It's comprehensive and well-written. 433 pages is a whole book on one small feature.

I've been using Java 5 at work and I must admit it makes developing proper frameworks possible, but it also complicates matters. It made my life as a framework developer nicer, but made the life of my user more difficult. Features should make my user's life easier, not mine. Simplicity is the key to good design.

Re: Cool Block Idea

Colin Putney was kind to inform me that #--> method from the previous is already implemented in Squeak! In Squeak, it's called #in:. So, the code before looks like this now:

((2 in: [:x| x * x ]) in: [:x| x + 5 ]) in: [:x| x sqrt ]

How cool is that?

Cool Block Idea

Howard Oh had the following suggestion on comp.lang.smalltalk.dolphin:

Block is one of the reasons that makes Smalltalk so lovable. But sometimes, block can make expressions very hard to read, because we human read parameter object first and then read inside the block just like Smalltalk runtime would do. This makes our reading cursor jump to right end and then back to left.

A guick example that can depict this point can be...

[:x| x sqrt ] value: ([:x| x + 5 ] value: ([:x| x * x ] value: 2))

An idea came up to me a few minutes ago,

Define a method for Object

Object>>--> aBlock

    ^aBlock value: self

This new method can transform the example expression to...

2 --> [:x| x * x ] --> [:x| x + 5 ] --> [:x| x sqrt ] 

What a cool idea! How I love messages and closures!

Why I Love The Smalltalk And Ruby Communities

This discussion on Lisp and its community is revealing. I've found comp.lang.lisp to be imitidating, not because of the hostility of some of the posters, but because everyone is so scary smart. It seems a lot of people have felt the wrath of impatient masters. The discussion shows a community taking a good long hard look at itself.

I remember not looking at PLT Scheme for years because of their poor behavior at Lightweight Langugages Conference Two. Matz gave a talk at the same conference and it's when Ruby won my heart. The community follows his lead. I have had nothing but great experiences in the Smalltalk and Ruby communities. I am thankful for that. The exchange of ideas and enthusiasm of people is contagious. I wish the same for the Lisp community.

I guess I'm shocked. I've always found Lisp folks to be helpful. The Lisp community has a lot going for it with two new books published last year. Renewed interest from a young audience is growing. I say forget the past and bury all hatchets. Start new. Lisp and Scheme are mad fun.

Upcoming Talks

I almost forgot to post about the talks that I'm giving in the near future. If you're in the Omaha area, please stop by. It's going to be a blast!

June 20,2006 - Reflective Testing In Java
Omaha Java User's Group
This is my talk from Smalltalk Solutions geared toward Java. The idea is the same, but the implementation is different. I will show how JUnit with other technologies can be used for contract enforcement and uncovering design smells. If you have any interest in meta/reflective systems or AspectJ, then this might be the talk for you. The presentation is itself written in Java5/AspectJ using the Eclipse/SWT APIs. Expect the unexpected! Learn how automation in testing can not only verify your code, but your designs as well! Stop code smells before they stink.

July 11, 2006 - Seaside
Omaha Dynamic Language User's Group
My infamous Seaside presentation updated for 2006! Same Smalltalk goodness, but with added more. I plan on adding topics for persistence and Seaside/Javascript integration. See the future of web development. Seaside is unapologetic in many of its stances and it makes for an extremely elegant framework. This is a great talk if you're curious about Smalltalk to see the power of the environment and language.

I hope to see everyone there at BOTH!

National Day Of Slayer

Yes, I will be observing National Day Of Slayer tomorrow. They are the band that got me started down the road to extreme music. Long live metal! I will be playing "Reign in Blood" and "South of Heaven" as loud as I possibly can.

A Dare

I have a simple dare. In fact, it's a triple dog dare to all developers. Are your ready? Here it is:

Stop using the same examples to show how great your favorite technology is.

Programming in general has "Hello, World" and every beginning programming book uses it. Even worse is the heavy use of "foo bar" in all its forms. Used to be cute, but not any more.

But, the worse by far is the fibonacci sequence used by every beginning functional programming article to prove the elegance of recursion or functional pattern matching. Come on. There are examples that prove it much better (pick anything in the real world). And that leads me to the final one...

ATMs are used as the example in almost every book in OO design. It's played to death and no longer interesting. Certainly, there's better examples than that out there now, right? And no, don't continue with the bowling example. It's already a cliche in all of the agile books.

Computer science is an exciting field filled with untapped potential and great ideas. But, cliched examples, while good for comparisons, fall flat in their simplicity. Fibonacci doesn't show the elegance obtained from functional programming. Much like showing that you can create a function to add one to prove the elegance of closures. I think a meatier example grounded in the real world will excite the reader much more. This is my dare. Dare to write an original example that makes me realize how clever you are and not @#$%^& ANOTHER FIBONACCI EXAMPLE?!

Code As Prose

Reading great code is like reading a great book. If you don't believe me, download Seaside or Dolphin Smalltalk. Of course, there's more examples than just that (Lisp 1.5 manual, Paul Graham's Lisp books, Structure and Interpretation of Computer Programs, etc), but I digress. You might now think I'm off my rocker and my brain is burnt from too much heavy metal music. But, I have a point to make.

There are simple rules to follow when writing: Outline your ideas; know your audience; and be concise. I'm sure there's more, but these are the three that I strive for. The funny thing is that these concepts correlate directly to code. Code is not merely communicating with the compiler and making things happen. If your software does anything of value or importance, it will be read by other people.

The act of design is the way we frame our ideas before we code. It allows us to plan out the high level view. It should not spell out everything, but give a blue print to how things will interface. It's the journey of thinking about the design that helps us. Code with a clear design is easier to maintain. Otherwise, it's a collection of incoherent thoughts glued together that might execute, but breaks often.

Writing your program for the computer is flat out wrong. In reality, the computer never really reads your code nor does it have to. It's the poor person awoken at three o'clock in the morning because a developer forgot to check for a null condition. It's the team interfacing their project on your library. In short, it's humans. We know this. Your audience is fellow developers. Take the extra time to name your variables well. Don't succumb to i,x,y, index, or each. Think about what business functionality you are implementing and write in that language. What if you had to give your code to someone non-technical? Could they understand what the code was doing? They should. Requirements live on in the program listing. Always strive for creating a domain specific language inside of your code.

Don't repeat yourself. I can't say it more simply. Don't be too clever and be concise. Prevent clutter from ruining the flow of a good program. Try to say the most with the least. It's good advice in art, writing, and programming.

There's probably more parallels that I could draw from, but I thought to keep this post simple. I enjoy reading books on good writing because I can try out new ideas for writing my code. I'm always asking myself how I could write something better for other developers to read. You can't learn from or maintain unreadable code. It's not hard to write well. It just takes practice. I'm amazed at how much code I read that is written for the computer. There's an over abundance of good code out there. The only way to become a great author is by reading great authors. Open source gives us a plethora of great code to admire and learn from. Get reading!

Is it all coming back to Smalltalk and Lisp?

Read Glenn Vanderberg's excellent article from "No Fluff, Just Stuff Anthology" now. He makes a strong case for Smalltalk, Lisp, Ruby and dynamic languages in general. The revolution is coming. Are you ready? Go get your squeak on!

Pair Programming: Is All The Time Too Much?

I work in an eXtreme Programming shop and we pair on ever single line of code. But, too much pairing can be bad. Some pairing partners, while excited initially to try something new, grow complacent after the honeymoon wears off. It's hard to keep them engaged. Pairing all the time stifles creativity because developers are simply uncomfortable taking risks in front of others (we are mostly introverted). It creates a strange group think atmosphere where pairs do what is comfortable and familiar. Few branch out and try new things. The ones that do, do it at home without the fear of failure in public. Sad but true.

Pairing on every single line of code is the path to broken windows. eXtreme programming enthusiasts scoff and grumble at this notion. Why? To ignore that developers are mainly introverts is fighting an uphill battle against human nature. The very thing that eXtreme enthusiasts claims that they embrace. Agility to me is about thinking to solve problems, not adding stifling processes or pithy mantras.

If pairing all the time is bad, is it alright to go back to our lonely cubes? NO! There is immense value in pair programming. In a good session, there's an unparalleled exchange of ideas and an unbeatable code review process. I find the good things happen if the pairing is not constant. Always pairing can be tiring mentally and physically. We all need time to recharge our batteries and reflect. Extended breaks can give us the spark of inspiration to solve that complex puzzle in our design that's been plaguing us.

The key is balance. Doing anything to the eXtreme risks team burn-out. Balance should really be the point of being agile. Take the advice of your mother. Everything in moderation is a good thing. Otherwise, you risk off going off the edge. Constant pairing erodes the benefits of it. Of course, the opposite is also true. The lonely coder can be a dangerous tumbleweed in your codebase.

My proposal is simple: Pair during design and creation of unit tests, not coding. This is where collaboration is a must and the most fun. A test-first approach helps a pair to design the domain language for business. It boils away all unnecessary abstractions and allows the pair to get to the heart of the problem. It becomes the design while providing the harness to verify its validity. Pairs challenge each other to write tests that express the business the most succintly.

Allow pairs to break apart to write the code that satisfies the tests that they write together. This allows personal time for reflection and to try out new ideas. It gives the much needed time to reflect and the exhilaration of collaboration. The pair should come back together after the code is complete and review what each other has done. A refactoring of each other's code is good at this point. Allowing the sharing of information without one pair becoming disenfranchised with a dominant other. Of course, if pairs feel the need to discuss issues as they come up in the code, they should. Remember, it's all about balance!

I have seen first hand the pitfalls of pairing too much. The code and design eventually suffer. Spaghetti ensues and no one wants to work on the brittle system. Quality slips and the team descends into finger pointing and negativity. Pairing only amplifies the problem because developers have no way to get away and heal their wounds. Everyone needs some time alone. But, we also need interaction to stay fully engaged. Everything to the eXtreme is bad. Balance is the order of the day. I will not offer any cute quotes or clever acronyms, just simple advice.

If you're thinking of trying out pairing or are just a burnt out XPer, try out my advice. It offers the best of both worlds. It's a meeting in the middle and is good to try out a new way of working together. You can have your cake and eat it too. Just don't eat only cake. You need your vegetables too.

More Info On Rails Presentation

Matt Secoske has posted some details of his talk on Rails, June 6, in Omaha.