Adopting a new development methodology is less about process change and more about attitude change. The binder is useful, but the mindset is vital.
Much of my work over the last few years has involved helping organizations “adopt” Agile. It is, after all, a poor, unloved orphan and needs to find a good home. The key to whether the new approach sticks doesn’t seem to be affected by how many checklists, process maps or charts of roles and responsibilities we provide; what matters is whether an organization can adjust their collective and individual attitudes.
There’s a great quote from the 14th Dalai Lama that says:
“If you don’t like what’s happening in your life, change your mind.”
Beyond the double meaning of “if you don’t like it, decide to like it” is the more important idea that to change your behaviors you need to change your thoughts.
Continue reading “Change your attitude and the process will follow”
I always struggled to see how what Lean teaches us about pull systems can be applied to software development processes. That was until I had an “Aha!” moment a little while ago helping a client apply lean and agile principles to their delivery process.
The big fat lie
I understand how queuing theory can help identify and reduce bottlenecks in processes and have used finger-charts and kanban-boards to do this for a while, but I still find calling this a “pull system” to be slightly disingenuous. All that’s happening is that more “stuff” is being pushed based on a trigger when certain buckets get too low. This reminds me of my annoyance with early technologies on the web that were touted as being “push” but were really just “repetitive-pull” (but not in a good way). I’ve never seen a software organization where the developers have said to the business or product people “we’ve got nothing to do, can you think up some new projects or features for us please?”.
Continue reading “Don’t push requirements – pull information”
Have you ever opened up a file of source code and flinched at the complexity that comes screaming out at you from the screen? Well I’m imagining an IDE plugin that could do the screaming for you.
There are many measures of code that are objective and metrics driven, but there are others that are more subjective and taste based. I can’t tell you from a quick glance how many afferent couplings there are in a given piece of code, but I do have an almost immediate sense of how elegant the code is. In my mind elegance is all about solving complex problems with simple solutions. That’s the art rather than the science of computer programming.
Continue reading “Simple code is music to my ears”
Have you ever noticed how teams who are new to Agile often struggle if they attempt to adopt just one or two of the XP practices? And have you noticed how the solution is often to introduce more practices?
I had been developing a theory about the interdependence of various software development practices when I got the chance to work through some of these ideas in a session I facilitated with some fellow ThoughtWorks colleagues. We uncovered some interesting connections and an important positive feedback loop that is worth being aware of when trying to help teams adopt Agile. The session happened at least a year ago, but I’ve only just been prodded into posting the output.
San Francisco is a wonderful place – I ended up having an interesting discussion last night with a self-styled “geek-at-large” about robots, ethics and unix while hanging out at a not-for-profit who are improving the world one wi-fi network at a time.
The robot maker’s argument was that robots don’t have to be super intelligent to carry out some pretty useful, robotic, tasks. He was suggesting that there’s a blind-alley in robotic research premised on being able to map and track everything in your environment in order to move and interact effectively. His argument was that instead you just needed to be able to identify a goal to move towards and be able to avoid collisions. That is a much simpler goal than understanding your whole environment.
Continue reading “Robot rights? My foot!”
My most recent project was helping a major online retailer to mature their build process as part of a wider effort to improve their IT effectiveness through the injection of development best practices.
When we came onboard manual intervention was needed for any of their builds or deployments to work and so it was rare for more than a couple of builds or deployments to be completed successfully in a day. Now we often have up to 1,000 builds running every day – what’s more the majority of them now pass!
This article looks at a few of the techniques we’ve had to put in place to enable this transformation and what we’ve learnt along the way.
Continue reading “Build Transformation across an Organization”
Discussions have been flying around the ThoughtWorks communication channels on balancing the risk of dynamic languages against the pain of static languages. This got me thinking about the similarities between what makes teams work well and what makes for good code and object interactions.
Continue reading “Programming considered harmful”
With Google measuring the efficiency of their code in the amount of gigawatts required to serve it to millions of people, optimizing applications can actually have a positive impact on the world.
Logicalis have put together some advice on how to reduce the impact of IT on the environment. The suggestions range from reducing hardware requirements through virtualization and other consolidation techniques to old favorites like double-sided printing, video-conferencing, electronic forms and turning off your desktop at night.
Continue reading “Can virtualization save the real world?”
We’ve had some discussions recently about best practices when creating Ant scripts, so I thought I’d write up a few of my favourites.
Managing Ant target dependencies
“depends” are great, until your build file gets bigger than a couple of screenfuls. You can end up with a crazy spaghetti monster of dependencies very quickly. On a few builds I’ve worked on we’ve had a basic rule:
Targets can either have depends or a body, but not both.
Continue reading “Ant Fu”
Coding really is become child’s play. This recent BBC news article points to some of the ways kids are being introduced to programming.
The good people at MIT have put together scratch a visual tool allowing kids to do drag-n-drop coding. The help screens give a good idea of how it works. Basically differently shaped blocks are put together (lego style) to form programs: a loop looks like a capital C and holds all the nested statements; booleans are pointy ended and only fit in pointy slots – likewise numbers are round and only fit in round slots … a nice simple introduction to strongly-typed languages. It actually fits pretty closely with how I visualise blocks of code, so it looks like a great way to introduce children to the coding mind-set. The welcoming colourful blocks are non-threatening and simple to understand.
Continue reading “Blocks of Code”