Hansei-Kaizen

Hansei-Kaizen Relentless Reflection and Continous Improvement tag:www.hansei-kaizen.be,2005:748aed1cca54298de546a749a31f6610 Textpattern 2008-07-20T10:28:29Z Nico Mommaerts nico.mommaerts@gmail.com http://www.hansei-kaizen.be/ Nico Mommaerts 2006-10-21T17:49:00Z 2007-08-27T15:08:31Z Last post tag:www.hansei-kaizen.be,2006-10-21:748aed1cca54298de546a749a31f6610/6cbfa966821cad629e68d0293f84a83e I haven’t posted here in months, I got married, I’m starting to build a house and I’m going back to school (in the evenings). So there won’t be much to read here in the near future. Nico Mommaerts 2006-05-11T04:26:00Z 2007-01-09T07:18:20Z this.setDraft(false) or this.post() tag:www.hansei-kaizen.be,2006-05-10:748aed1cca54298de546a749a31f6610/51ea88a3760bc970dcf6b2e9761bd7ed I’m doing a lot of Swing lately and there is something that irritates me even harder as people who drive in the middle lane all the time: <code>setEnabled(false)</code> This method is defined on the JComponent class so it gets used a lot. It irritates me a lot. How setLogical(false) does this sound? Imagine having to turn off the engine of your car with car.setEngineRunning(false)! It’s hard to read and it implies changing a property of an object, when instead you are changing the behavior of an object. Of course, difference in behavior of objects is often if not always determined by the value(s) of one or more properties of that object, but I shouldn’t have to know about that. That’s up to the implementation of the object! Doesn’t this sound better? <code>setDisabled()</code> Or even better: <code>disable()</code> Now I’m just sending a message to an object saying: dude, disable yourself, I don’t care how, just do it. Funny thing is that those methods (<code>enable()</code> and <code>disable()</code>) do exist, but they are already deprecated since JDK 1.1 and replaced by <code>setEnabled(boolean)</code>. I wonder why that is? A related but not entirely the same post by <a href="http://silkandspinach.net">Kevin Rutherford</a>, which made me think about this more consciously: <a href="http://silkandspinach.net/blog/2004/07/avoid_boolean_p.html">avoid boolean parameters</a> Nico Mommaerts 2006-04-30T07:12:00Z 2007-11-24T09:30:04Z Multiple bounds in Java 5 generics tag:www.hansei-kaizen.be,2006-04-12:748aed1cca54298de546a749a31f6610/a0e00d25a9326bcf187ea7dce5b71218 I'm doing some custom rendering of JasperReports designs, this is part of the domain model I'm working with: <img src="http://www.hansei-kaizen.be/images/34.png"/> There are more subclasses of JRDesignGraphicElement, but not all of them can have a box drawn around them, only the ones in the diagram are 'boxable'. Being boxable as an element adds some extra properties to that element, for example the width of the leftborder or the padding (I omitted most of the properties in the diagram for brevity). The way it is implemented in JasperReports is a bit unhappy (more about that later), but since it is an external library I have to deal with the existing domain model. So far so good, the problem starts when I want to write a method that takes a Jasper element and draw a border around it. Something like this would seem right: <code>void drawBorder(Graphics2D gg, JRBox box)</code> The problem with this approach is that to be able to draw a border around an element, I need also the coordinates of that element and they are not exposed through the JRBox interface, but are defined in the JRDesignElement class. Bummer. I could cast it to a JRDesignElement though when I need the x, y, width and height attributes, and that probably wouldn't be a problem, as there are no other classes which implement the JRBox interface that are used in my code. But doing that would give me an icky feeling. It would create an unchecked (at compile time) precondition for using this method, and since I'm using a compiler anyway, I'd better use it, right? The following declaration solves the problem: <code><notextile><E extends JRDesignElement & JRbox> void drawBorder(Graphics2D gg, E e)</notextile></code> What this is saying is that E is of type JRDesignElement and of type JRBox, effectively letting me use methods and properties of both types. <code>e.getX();</code> and <code>e.getLeftBorder()</code> is legal code inside the method declaration, and the compiler will enforce that I don't pass on any objects of type JRDesignElement that don't implement the interface JRBox to the method. Pretty sweet stuff I think. You can even specify more bounds if you want like <code>E extends N & N1 & N2 & ...</code>. One remark though, Eclipse 3.1.2 can't seem to handle multiple bounds, the code compiles, but code completion doesn't show all the available methods and sometimes the background compiler shows errors that dissapear after compiling the project. IntelliJ has no problems with this. (of course:)) I mentioned before that I think the JRBox functionality is a bit unhappily implemented, actually I had been thinking about this on the way home the day I wrote the drawBorder method, but couldn't find a better solution myself. The JRBox interface is inconvenient first of all because of the problem laid out before, but also because of the fact that every class that implements JRBox has the same tedious implementation (== code duplication). The easy way would be to create an abstract class JRBox that inherits from JRDesignGraphicElement and let all classes that are boxable inherit from JRBox. Technically speaking this would be a good solution but it would violate some OO principles. Elements can be boxable, which implies a 'flavor' of an element, but doesn't mean they are a box. How else would you implement this? Any suggestions? In a more versatile language like Ruby we have mixins which are perfect for this situation. The implementation could look like this: <pre>module JRBox def left_padding ... end def left_border ... end end class JRDesignElement attr_accessor :x, :y, :width, :height end class JRDesignGraphicElement < JRDesignElement end class JRDesignImage < JRDesignGraphicElement include JRBox end class JRDesignTextElement < JRDesignGraphicElement include JRBox end</pre></pre> Writing the method drawBorder wouldn't be a problem either, because of <a href="http://en.wikipedia.org/wiki/Duck_typing">'duck typing'</a>. <code>def drawBorder(design_element)</code> would be enough. As long as the type of design_element has the methods and properties we use in the method the world keeps turning. I looked a bit around for mixin support in Java, and the closest I could find was the <a href="https://rapt.dev.java.net/nonav/docs/api/net/java/dev/rapt/exploratory/mixin/package-summary.html#package_description">rapt</a> project. I implemented the same domain model using rapt, but the code became so ugly I didn't even compile it (you have to compile with apt, not with javac which would also require some java command line skills which are somewhere in the back of my skull beneath a deep layer of IDE-using brain cells). Nico Mommaerts 2006-04-16T05:40:00Z 2007-11-27T11:45:28Z Some thoughts on Team System tag:www.hansei-kaizen.be,2006-03-17:748aed1cca54298de546a749a31f6610/2e666bb0495ae7b0a05b1f3f7746fd44 Some thoughts I had after attending a presentation on Team System… <h3>Benefits of Team System (besides the functional ones)</h3> The fact that this is a product from Microsoft and not from the open source community means that the barrier to use unit testing, continuus build etc will be a lot lower than it is now for some companies. While using open source products in a Java project is almost a sine qua non, there still seems to be a bit of a distrust against open source in some .NET projects. (relatively speaking, compared to Java projects) This also means, trusting the gigantic marketing machine that is Microsoft, that Team System will probably reach a lot more (MS) developers than the agile community has been able to so far. Because don’t be mistaken, there are still a lot of people out there who haven’t even heard of the concept ‘agile’, or of unit testing, testdriven development, or even of an issue management system (certainly not only MS developers!). <h3>Everybody will be Agile!</h3> So that would seem like a good thing right? More and more developers/project managers/testers/... are being exposed to agile practices, isn’t that what we want? Well…not exactly. Practices serve a goal, and the same practice may not always be appropriate in every situation to achieve that goal. If you don’t know or understand the goal of the practices you are following, you may be in for an unpleasant surprise somewhere along the road. <h3>What about MSF for Agile?</h3> In <a href="http://www.stsc.hill.af.mil/crosstalk/2005/12/0512miller.html">this article by Randy Miller</a>, he explains that MSF for Agile is actually an implementation of the agile philosophy (the agile manifesto), adapted to specific circumstances experienced over the years by Microsoft teams where the classical implementations of Agile were deemed unsufficient. <blockquote> It [MSF for Agile] also presents alternative practices to those commonly found in many agile processes. </blockquote> For example, while Microsoft recognizes that having an on-site customer is a key factor for a successful project, they also know that this isn’t always possible, and offer personas (invented by <a href="http://www.cooper.com/content/insights/newsletters/2003_08/Origin_of_Personas.asp">Alan Cooper</a>) as an alternative. MSF for Agile provides you with a lot of guidance and building blocks, all beautifully integrated with Team System, but it doesn’t provide detailed instructions on how to handle day-to-day stuff like SCRUM does for example. You still have a lot of freedom to determine how the project will be run, and that’s where a good understanding of agile is needed. Using MSF for Agile won’t magically make you agile. <h3>The danger</h3> I think there is a danger that people who have no previous knowledge about agile will start equalizing ‘Agile’ and ‘Team System’. I’ve already seen this happening on a team using a custom build Team System-like product, where project managers were way too rigorous in following the practices laid out by the tools, forgetting (or not even knowing) why the practices were there in the first place, effectively crippling productivity and quality. <h3>What can you do to avoid this?</h3> Start learning Agile. Read about MSF for Agile. I have the feeling that Team System gets most of the attention, but in fact you can’t view at Team System without looking at MSF too. They are intended to be one system. <ul> <li>There is a <a href="http://wiki.systemsthinking.net/Systemsthinking/BookList.html">list with good books</a> on the Systems Thinking wiki where you can start reading.</li> <li>If you live in Belgium you can start attending the <a href="http://wiki.xp.be/Xpbe/XpBeMeeting.html">XP BE user Group Meetings</a>, I’m sure there are similar user groups in your neighborhood.</li> <li>Read <a href="http://www.technorati.com/blogs/Agile">blogs</a>.</li> <li>Doing a project with someone who knows agile won’t hurt either, but may be a bit more difficult to arrange.</li> </ul> Nico Mommaerts 2006-03-20T20:22:00Z 2007-09-03T05:54:19Z Goodbye Firefox tag:www.hansei-kaizen.be,2006-03-17:748aed1cca54298de546a749a31f6610/1947c4740971d0d62049fd783716e736 <img src="http://www.hansei-kaizen.be/images/33.jpg"/> I think I’m one of the earliest adopters of Firefox around. It happened quite by coincidence, just on the day I switched to using Linux, Mozilla released Phoenix 0.1. I was looking for what browsers were available on Linux, and stumbled upon Phoenix. Back then I fell in love with it because of its small footprint, and simplicity (certainly compared to Mozilla). I’ve been using it ever since, going from Phoenix to Firebird, and finally from Firebird to Firefox. I’m singlehandedly responsible for dozens of people switching from IE to Firefox, so it is rather ironic that now I’m switching back to IE (on my Dell box at work, at home I am a Safari loving guy). The reason is Firefox’s memory usage. Last week I spent half a day debugging an application that failed to insert some records through its JDO layer because it didn’t have enough memory. Okay, granted, JDO (Kodo) shouldn’t fail silently in this case, but still, it was very frustrating. And maybe it didn’t have any relation to my memory at all, but it did make me discover how much memory Firefox actually consumes. >200Mb memory usage for a browser isn’t something I’d call a feature. <a href="http://weblogs.mozillazine.org/ben/archives/009749.html">(the Firefox developers respond to the reactions on the memory usage of Firefox 1.5)</a> I did change the max_total_viewers setting, and I realize that the excessive memory usage may be caused by one of the extensions I use (GMail reportedly also causes a memory leak in it’s use of XmlHttpRequest, although they deny it), but still it annoys me. So the last few days I’ve been happily browsing along using <a href="http://www.avantbrowser.com/">Avant Browser</a> It has popup blocking, tabs support, and it includes <a href="http://kb.mozillazine.org/SessionSaver">SessionSaver</a> -like capabilities. All that I need (for my non web developing needs)! Goodbye Firefox, maybe I’ll see you again on a browser reunion party or something. (the default install does like look shit though, you’ll have to tweak it a bit to look a bit decent if you decide to give it a go) Nico Mommaerts 2006-03-13T03:22:00Z 2008-02-11T16:34:29Z Guy Kawasaki tag:www.hansei-kaizen.be,2006-03-12:748aed1cca54298de546a749a31f6610/663d2080738f6c480647ee5d5520e459 <a href="http://www.guykawasaki.com/">Guy Kawasaki</a>, the man who invented evangelizing in the early days of Apple. I keep running into his name ever since I’ve heard of him. Today it was when I was signing up for an account at <a href="http://www.istockphoto.com/index.php">iStockPhoto</a>, in their signup form there is the obligatory question “How did you hear about iStockphoto?”. Guess whose name was among the more common options like “Google” or “Magazines”? Yep, Guy Kawasaki. The funny thing is, I was looking for “Blogs”, cause I learned about iStockPhoto through Guy Kawasaki’s blog… Nico Mommaerts 2006-03-07T16:53:00Z 2007-09-03T05:54:31Z Clean up your code! tag:www.hansei-kaizen.be,2006-03-06:748aed1cca54298de546a749a31f6610/9bf5e0f6bd80b3711824e4d28782269e [Update] Kathy Sierra talks about the same subject in the post <a href="http://headrush.typepad.com/creating_passionate_users/2006/03/code_like_a_gir.html">Code like a girl</a> I love my job. I love it when I have created an application that improves someone’s work or life, or just looks cool. I love the process of creating that application, the writing of the code. My grandfather is a carpenter, and he also loves his job. When I was still young(er), and I visited my grandparents in the weekends, he was always working in his atelier. Nowadays he isn’t working with wood as much as he used to, but when he speaks about it, you still hear his passion for wood in his voice. He loves creating furniture, and he loves the process of doing it. Because he loves working with wood so much, he pays attention to every little detail. When you see one of his finished pieces, you can see it was made by someone who loved creating it. He is proud of every piece he made, as he deserves to be. Since I love my job, I pay attention to every little detail of my work. One of the most obvious parts of a programmers work where you can see this attention is the look of the code. No matter what patterns you use, or how many bugs are still in your code, you can still make it look good. In fact it’s the easiest thing to get right when writing code, it doesn’t require any extra thinking or time at all, there is no learning curve involved, you just do it. I am proud of the way my code looks, just as my grandfather is proud of the way his finished piece of wood looks like. We are craftsmen, we take pride in our work. But why does it seem so hard for some people to make their code look decent?! I’m sure you have all seen examples of what I have in mind. Eclipse for example, displays little yellow triangles on each class that has warnings, and on packages that contain classes with warnings. Some projects don’t contain classes without warnings, literally thousands of warnings. Some code is littered with warnings of unused variables, unused private methods, unused imports or incorrect javadoc tags. Those classes typically have large blocks of code that are commented out instead of deleted, a random number of white lines between lines of code, inconsistent use of curly braces, whitespace and other formatting idioms. Only getters and setters seem to be documented but that mysterious method <code>public void deleteSomeRecords(int arg0, int arg1, boolean xf5)</code> isn’t. You all know the horrors I’m talking about. Sloppy looking code. So here are some guidelines for writing code, I call it “the etiquette of writing beautiful code”: <ul> <li>the button on your keyboard with the arrow on it that points left, above your enter key, is called the backspace key. It deletes characters. Another key that has the same functionality is the ‘delete’ key. Open up notepad, gedit, textedit or whatever, and try it out. You’ll see it is much easier as putting // in front of every line of code you don’t want anymore, or for the power users among us, putting the block of code between /* */. If you suddenly need that entire method back that you deleted before, well, that’s why we use a source control system (yes it has other uses as blaming people!). Don’t abuse the ability to comment out code as a way to remove it!</li> <li>documenting your code is considered a best practice, but don’t you think writing “<code>i++; // this increments the variable i with one</code>” is a bit too much? Try naming your methods and variables in such a way that you don’t need to comment them. With generics in Java 5 en .NET 2.0 one of the major uses of commenting has disappeared. If you are feeling extreme, write a unit test that documents the expected behavior of your methods, such a test may be useful for other things too, who knows? Oh yeah, while you are at it, learn the documenting system of the language you use, so other people don’t get thousands of javadoc related warnings in their IDE.</li> <li>please oh please, I know it is jolly good fun to insert a random number of white lines between your methods, but format your code consistently! It doesn’t matter where you put your opening curly brace, and how many whitespace you put after your commas, but please be consistent about it. Most editors even format your code for you, so it’s not a tough job! </li> <li>copy+paste are the tools of the devil! Making it so easy for programmers to copy other blocks of code is the worst invention ever! Every IDE should disable copy+paste, or limit it to one line. Understand the code you write, don’t copy a bunch of lines where one line does what you need, and the others…well, you actually don’t know what they do… Copying the same piece of code over and over again may say something about the design of your application too…</li> <li>Update Thomas: Never use abusive language in your comments like “WTF, who made this crappy code” or “This is method is sh*t”. First of all it’s not professional and it gives a bad impression to your customer.</li> <li>feel free to add your own rules of ettiquete, put them in a comment and I’ll add them here, I know every programmer has his pet peeve, today you may freely admit them</li> </ul> This rant was out of love and respect for the code. Note: code can look great, but suck at its implementation, it can also look bad, but have a clean implementation. There is no immediate relationship between the ‘look’ of code, and its implementation. Ugly looking code may work perfectly, but then again, that wasn’t the point of this post, now was it? Nico Mommaerts 2006-02-24T19:13:00Z 2008-02-11T16:35:06Z My Job Went To India [Part 2] tag:www.hansei-kaizen.be,2006-02-24:748aed1cca54298de546a749a31f6610/9940f95bb33fe7d6529d80c06ca8d29b I finally finished the entire book, there were two paragraphs in the final chapter that I wanted to share. <blockquote> The real meat of your career is not the promotions and salary advances. It’s the time you spend working toward those advances. Or, more important, it’s the time you spend working regardless of the advances. </blockquote> <blockquote> If this is the core of your work life—the actual work—then you’ve already arrived at your destination. The goal-oriented, destination-focused thinking that you usually do leads only from one goal to the next. It has no logical end. What most of us fail to realize is that the path is the end. </blockquote> This is the best description for what the book is about, and in a way, also what this blog is about. This book is a great complement for <a href="http://www.amazon.co.uk/exec/obidos/redirect?link_code=as2&path=ASIN/020161622X&tag=thelifeofabeg-21&camp=1634&creative=6738">The Pragmatic Programmer</a>, whereas that book focuses on technical ‘attitude’, this book focuses on your attitude and behaviour in general (in the context of the IT industry of course). If you are starting out in the industry, and read these two books, you’ll have a head start on the rest. Nico Mommaerts 2006-02-21T15:41:00Z 2008-02-11T16:35:14Z Agile Open 2006 tag:www.hansei-kaizen.be,2006-02-21:748aed1cca54298de546a749a31f6610/e359c3c549d503ab79dff08674e4c7f5 <blockquote> The Agile Open conference is the second international unconference on agile development. It is an Open Space intended for software development and business people from all walks of life, taking place on April 27th and 28th, 2006, in Mechelen, Belgium … an amazingly open, warm and lively community space where people spark new insights in and relationships for collaborative (software) development and doing business together. </blockquote> From <a href="http://www.agileopen.net/">Agile Open</a> Unfortunately I won’t be there, one of the downsides of not being self-employed is that can’t you frequent every conference you’d like (the upside is that when I do, my employer pays all expenses). As you can read on <a href="http://www.agileopen.net/Conference/OpenSpace.html">their website</a>, it will be an Open Space conference, I’m kinda curious as to how such a conference feels like, but alas, my curiosity won’t be satisfied this time. I know that there must be something good about the Open Space format as I know a few very intelligent people that make their living out of “Open Space Communication”. Anyway, if I look at the sessions that were covered last year, it looks like it will be as interesting, engaging and funny as the XPDays2005 in Rotterdam. The location of the Agile Open 2006 is btw the same as the one of the XPDays2004, which I did attend, and I can tell you, the Elewijt Center is a top-notch place. Nico Mommaerts 2006-02-20T05:02:00Z 2008-02-11T21:15:12Z You get what you measure tag:www.hansei-kaizen.be,2006-02-08:748aed1cca54298de546a749a31f6610/b42d37f1d942f6b08010a96c52c951b7 2 weeks ago was another <a href="http://wiki.xp.be/Xpbe/XpBeMeeting.html">XPBE meeting</a>, this time hosted by the <a href="http://www.erggroup.com/default.htm">ERG Group</a>. The subject at hand was ‘Management Metrics’. <img src="http://hansei-kaizen.be/images/18.jpg"/> I didn’t quite know what to expect first, but thankfully <a href="http://blog.nayima.be/blog/Entry20060215.html">Pascal Van Cauwenberghe</a> gave a small introduction first (he also led the entire workshop). We were to conduct a workshop created by <a href="http://www.agilespi.com">Jason Gorman</a> and <a href="http://www.duncanpierce.org">Duncan Pierce</a>. We were separated into 4 teams, each team had someone from the ERG group. Our assignment was to find a metric to measure something that the ERG group wanted to measure on their projects. To be more specific, the team I was in had to find a metric to measure the velocity of the development, analyst, test and support team. In the following rounds we had to: <ul> <li>make a list of possible metrics</li> <li>choose one metric and present it to the other groups</li> <li>every group passed their sheet with their metric on it to the adjacent group</li> <li>each group had to find ways to ‘cheat’ the metric; to still look good when measured by the metric, but not actually doing a good job/not doing much effort</li> <li>each group got the chance to improve their metric </li> </ul> For example, we chose the number of use cases completed/fixed time-span as a metric to measure the velocity, this could be cheated by increasing the granularity of the use cases, or by developing half-assed use cases (which raised the problem have not having acceptance criteria of use cases going from dev to test). We improved our metric by giving use cases cost points, and measure the #cost points/time completed. What did I learn from this? <ul> <li>you got to think about what metric to use to measure something</li> <li>every metric can and probably will be cheated by some people, so don’t spend to much time on designing your metric to counter this</li> <li>you almost always need more as one metric</li> <li>don’t be afraid to use qualitative metrics (customer satisfaction, fun, ...; as opposed to quantitative metrics)</li> <li>XPBE meetings are jolly good fun and very educating!</li> </ul> Thanks to <a href="http://blog.nayima.be">Pascal</a> for sending me his powerpoint he used on the meeting so I didn’t make any flagrant mistakes and so I could credit the right people