The intersection of technology and leadership

Category: Development (Page 8 of 18)

Notes from Michael Feathers’ Brutal Refactoring

Here’s my notes from the four hour workshop by Michael Feathers on Brutal Refactoring. I’m trading off timely information for something that probably could be more succinct or polished with a bit more time.

Michael opened with the discussion on what is Clean Code versus Understandable Code, and why each is important. He makes the point, using some good examples from different languages, we can live with understandable code, and there is a cost to having Clean Code, particularly when you have it. He explained it through good relationship with Behavioural Economics, taking about how the incentives for people maybe aren’t quite set up right.

He asked a question, “Is it easier for people to add code to existing place than to create a new method/class/etc? Why?” It’s a good analogy, and something that you even seasoned, diligent programmers often fall foul when working in small increments.

There were some further good discussions about “Understandable” being contextual. Such as, a C++ macro might seem “magic” to non C++ users, but could be quite familiar. This remind me of the learning curve, my former colleague Dan North is going through with Rails at the moment. A nice reflection on some messages I talk about in my “Beginner’s Mind” talk.

Anyway, back to the tutorial. Feathers says, “We should’t be surprised by very large methods. incentives are set up wrongly. Though not sure what we can do about it.” He further acknowledged it wasn’t a “bad coder’s” action, but a systemic effect, “It’s the result of the system between us and the code.” I think this is quite important to note because I think the social system that software development occurs in is important as to what code you get up. For example, when you build teams, having an agreed code standard and consistent technical direction is essential into setting up a different system that incentivises different behaviour. If you know you’ll need to come back to something, and change it, you’ll want to leave it in a good state. If you want the respect of your peers, you’ll want to leave it in a good state.

Feathers then talked about some great visualisations he’s been working on. He’d get on great with many of my colleagues, particularly Erik Dörnenburg who loves to champion this sort of stuff. I agree when Feathers says, “Code has a particular shape,” when you’re looking at a particular system.

Feathers than covered a good deal of stuff as shown in the Mind Map. I have some rough notes.

Feature Clustering

  • Listing out features and looking for commonality. Sometimes you look for common arguments across classes/methods. Sometimes it’s about common data (Data Clumps as Fowler talks about in his book).
  • Look for Locality of information (or encapsulation in OO talk)

Rapid Scratch Refactoring

  • A bit of regret not focusing more of it in his book.
  • You learn a lot my attempting stuff out and then seeing, “What could be?”
  • Some discussions on the danger of making these too much of a big leap and never reaching for it. (Just another reinforcement about clear vision and essential leadership to keep people heading in the right direction”
  • I found it interesting he liked to do it in a plain text editor instead of an IDE. Feathers talked about the distractions of syntax highlighting. I find that I learn a lot more information (and can try things out faster with an IDE like IntelliJ or Resharper)

Twisting Classes

  • Breaking down a class based on use rather than adding more
  • Step by step process of creating a new role (via interface or superclass and using that in a consumer rather than the original)
  • Feathers recommends a very riguourous command query separation

There’s lots of other small gems included. Some notable tweets worth saving:

  • “Branches often biggest impediment to refactoring in large orgs.”
  • “Narrowing scopes: often we gain leverage by moving temporary variables coser to their points of first use”

Long Feedback Loops

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night because he wanted to add that extra polish and make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step. The real problem the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

Scandev 2011 Summary

A couple of weeks ago 700 geeky Swedes (and a handful of other Scandinavian people) descended on Gotheburg to attend Scandanvian Deveopers Conference. It was the first year that I went along and enjoyed the experience of this conference.

The two days had plenty of options – with eleven (yes eleven!) parallel tracks including language specific ones (java, .net), mobile, upcoming things, agile methods, web, SOA, etc. Something for everyone for the most part. This invariably brought a whole collection of interesting speakers from plenty of different walks of life. I met plenty of new people and reconnected with many others.

My key takeaways
Just like many of my colleagues, I’m interested in the “what could” be for functional programming. I have my own thoughts on its applicability, relevance and maintainability to my day to day work, however I made myself attend several sessions to see what it was. Neal Ford (great presenter as usual) did a great introductory session to the mindset behind functional programming. I’m glad to see that my studies in this at university meant a lot of it I already understood (first class functions, recursion, etc). I understood, though can’t extrapolate the strength of closures (at least the way that Neal was describing them), and the real world application of currying.

I enjoyed listening to Douglas Crockford talk about the new changes in the upcoming update to the Javascript language. I found him honestly refreshing – talking about which features to avoid (and why) and which things have been added to make users’ lives much easier and still maintain backward compatability. I can’t say that I learned a lot that I could immediately apply but had to laugh at pictures like this:

I also really enjoyed Matthew McCullough’s talk on git that was both insightful and entertaining on the internals, practicals and plenty of live demonstrations using the tool. As a fairly new user to the tool, I learned quite a bit and know more about what I don’t know and can work to fill that gap.

I have to admit the keynotes didn’t really get me thinking any differently, but I think that’s more of a function of having followed Alistair Cockburn’s thoughts for some time and having worked with and understanding change (the topic that Henrik Kniberg talked about).

Long Feedback Cycle on a 4 Year Old Project

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night to reskin our interface using JGoodies because he wanted make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step towards a bigger change. The real problem was that the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

Book Review: Object-oriented Software Metrics

Working for a client in Berlin, I find the plane time where I normally catch up on some reading. Services like Read It Later make bookmarking online pages for offline reading a pleasure. This morning’s trip, I finished reading a book Michael Feathers tweeted about that. Titled, “Object-oriented software metrics”, and published 15 years ago I found this book most easily from a online second hand book store, and have to say I enjoyed many aspects to this book.

Wondering how much interest a metrics book could be, the author did well to keep the short book punchy and brief. I enjoyed the conversational style of the writing, and the pragmatic nature of his recommendations, such as “I put the threshold at zero so that we explicitly consider any violations.” He starts the book describing metrics and that they should be used for a real purpose, not just randomly corrected, and something I’m pleased resonates very well with a chapter I’m contributing to a book. It’s obvious he comes from applying metrics with real purpose in the real world, talking about examples where various metrics might be used to drive various design choices, or further investigation.

The author divides the metrics into two sections, the first focusing on metrics related to estimating and sizing, or project planning. The second set focuses on design metrics related to code. The metrics that emphasise estimation piqued my interest as a reflection on how estimation methods used to be run, or maybe in some places still are run such as Developer Days per Line of Code, or his suggestion on Developer Days per Public Responsibility. I think the second set proved more relevant to me.

The author shares some of his preferred metrics thresholds and, they too, resonate strongly with my own views of size of methods, number of instance variables in classes, etc. In fact, I’d almost say they were definitely much more extreme such as 6 message sends per method, with my preferred number between 5-10 depending on the team I’m working with. Part of this, something that the author emphasises, is also heavily influenced by the programming language of choice.

Few of the metrics talked about were new to me, having made use of tools like Checkstyle and PMD, although I found he used several I’ve not really tracked such as number of classes thrown away, number of times a class is reused and the number of times a class is touched, something I’d like to ponder on a lot more. One metric I’ve also never considered collecting or tracking is number of problems or errors reported by class/module though I suspect the overhead in tracking this may outweigh the benefit it brings because it’s much harder to automate this.

His emphasis on the influencing factors on code metrics also got me reflecting on my own experiences, once again strongly resonating with my own experiences. His mentioning of key classes resonate with the domain model described in Eric Evans’ Domain Driven Design. I would also anecdotally agree that the type of UI heavily influences the number of supporting classes with technical interfaces (i.e. APIs) requiring less classes than rich GUIs. I like a lot of the distribution graphs he uses and will definitely consider using these in the future.

I’d highly recommend this book if you’ve never really sat down and thought about using code metrics on your projects. It’s got me thinking about a number of other interesting side projects about visualisation and further feedback loops on projects.

Swarming on Stories

On leading a new team, I’m definitely trying to be as open to trying new practices particularly as I feel it is an important part of The Beginner’s Mind (topic to be talked about at InfoQ). One of the new practices we tried last week was swarming work on a user story.

Normally, our natural work in progress limit for development is limited by the number of pairs we have on the team (although not all tasks need pair programming). This time, I’m the odd one out, acting as tech lead and needing to do a handful of other activities including working to maintain constant flow between our BA and QA functions and guiding the development in the right direction. In a different world, I would have started a story and with other duties, probably be quite interrupted in flow to completion.

This time, we broke down a story into as many tiny tasks as possible, discussing those that needed some design elements, or identifying those tasks that could be taken in solo (such as knowledge gathering with report back) and the three of us worked on the same story. The result was a very minimal work in progress limit and actually, we made a lot of progress in a rich environment where we are learning about not only the constraints of the current build and development systems, but working out the best ways to implement what we need and deliver value.

I’m quite happy to report that I’m really liking the swarming on stories. It helps me feel involved in the way that things are going, rather than keeping on top of too many ongoing threads. I do wonder how many people it would be to scale to, but for now, it’s working for us. Inspect and amplify, or inspect and adapt!

Picture kindly borrowed from Max xx’s Flickr stream under the Creative Commons licence.

java.io.tmpdir on Mac JDK1.6

Diagnosing a test failure on a new machine today, I stumbled across this different behaviour in JDK1.6 on my Mac, running OSX10.6.6 where:

System.getProperty("java.io.tmpdir")

was returning a strange value of /var/folders/Ob/Ob-aqIAEG2WzgTa5ezd5qU+++TM/-Tmp-/ (note the plus characters) instead of the normal value of /tmp it used to return. Fortunately this property can also be set at on JVM start, by passing it in as an environment variable

-Djava.io.tmpdir=/tmp

UTF-8 not supported by ResourceBundleMessageSource

Every time I return to Java, I’m reminded by how hard simple things seem to be. Localisation is often quite important for applications, so I expected UTF-8 support out of the box with Spring Framework and Java via their ResourceBundleMessageSource and standard ResourceBundle classes.

Things are never that simple as pointed out by the following articles:

Despite the poor documentation not noting this, there are work arounds described in the links above. Alternatives include using the, much longer named, ReloadableResourceBundleMessageSource and InputStreamReader classes.

Disabling Flip Screen

When using R#, or IntelliJ, the keyboard shortcuts often involving hitting some combination of CTRL, ALT, SHIFT. Unfortunately my laptop (using an Intel graphics card) for Windows 7 has CTRL+ALT+UP and CTRL+ALT+DOWN bound to flipping the screen.

Really surprising the first time and grew troublesome when I wanted to rearrange the order of some methods.

Disable this keyboard short cut on the dialog as shown above. This was accessed via the Control Panel – Intel (R) GMA Driver for Mobile.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑