https://www.hbhau.net/feed/atom/ 2012-07-13T05:17:58Z hbhau.net Copyright 2012 WordPress http://www.hbhau.net/?p=104 <![CDATA[Clean Code, the devil’s in the detail]]> 2012-04-02T12:38:35Z 2009-10-22T10:51:09Z Brett Henderson brett.henderson@gmail.com http://hamstaa.hbhau.net Continue reading ]]> One of the driving forces of “Clean Code” is that while it takes a certain amount of time to write code, that same code is read many times. Clean Code is aimed at reducing the reading and hence understanding time of the code.

We recently had a practical session, as part of our continuous learning practice, on TDD. After the first few tests, Doug got into some serious refactoring to make the code clean. As Doug progressed, I found myself becoming increasingly frustrated with the numerous methods, many of which had 1 or 2 lines of code, that he created.

I started trying to understand what Doug was trying to achieve and why I was finding it frustrating. As we discussed the aim of Clean Code and how Doug would “read” the code, it dawned on me that the difference was in detail. Doug would read the initial method, accept the definition inherit in the method names called, and drill down to those lower methods only when required. I on the other hand found I needed to drill down through the many layers of methods to better understand the initial method.

It was this difference to how we went about understanding a program that was making his extreme Clean Code approach work for Doug and not for me.

In previous lives both Doug and I have done a Myers-Briggs assessment and interestingly he is an N while I’m an S. In the Myers Briggs assessment, the Intuitive (N) preference person works from the “Big Picture” drilling down to detail when required, while the Sensing (S) personality is the opposite.

When I did my Myers-Briggs assessment we discussed the need, when presenting to a room of people, to take into account the various understanding approaches inherit in the S and N preferences. Similarly, when you are teaching, my wife informs me, you need to take into account the learning styles people have. For example Auditory versus Kinesthetic.

So, when you are “cleaning” code, take into consideration that the people reading it in the future, may not approach it the same way you do. You need to strike a balance between cleaning up the code into more manageable methods, but not to the point where you have many layers of increasingly smaller methods. Not everyone will save time reading this code, but rather it will take them significantly longer.

]]>
http://www.hbhau.net/?p=61 <![CDATA[Old Skool UI Design]]> 2008-07-01T03:20:16Z 2008-07-01T03:20:16Z Brett Henderson brett.henderson@gmail.com http://hamstaa.hbhau.net Continue reading ]]> Andy recently pointed me at an interesting article, “The Paper Version of the Web” that shows some great examples of UI designs sketched on paper. In the article Sean collects together some of the publicly available UI sketches for well known websites like Flickr and Twitter.

At Ephox, we have quite a lot of UI design required and as such we’ve tried a few different things from quick Java mock-ups to Photoshopped images. To me however the best solution is the paper sketch. Why, well other than it being pretty cheap to develop and modify, anyone can do it, including the “client”. Finally, there’s also no chance you will be tempted to use the “prototype/mockup” as the basis for the final version.

]]>