tag:blogger.com,1999:blog-15549868730862321382024-02-08T12:07:12.553-08:00Iridescent UrchinSteve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.comBlogger126125tag:blogger.com,1999:blog-1554986873086232138.post-33763526086847843872010-05-27T19:44:00.001-07:002010-05-27T19:44:13.445-07:00Time to move onFrom my darling wife: <br /><br />Well, folks, it's finally happening... the Hayes family is leaving town. We've been very happy here for the past nine years, though, and we're certainly not going to leave without saying goodbye! <br /><br />We've decided on a date for a big going-away 'do, but we don't have a venue yet. (We've decided we're not quite crazy enough to have this one at home, especially with no furniture!) So here's the deal: you let us know if you're free, and we'll find a spot for us all to raise a glass together.<br /><br />Date: Saturday, June 12<br />Time: Afternoon - maybe 2ish until 6ish?<br />Venue: TBD<br /><br />Kids are welcome, just please let us know how many!<br /><br />RSVP ASAP to this <a href="mailto:amanda.l.hayes@gmail.com">amanda.l.hayes@gmail.com</a>. Here's hoping you can make it!<br /><br />Much love,<br /><br />Steve, Amanda and JamieSteve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-17495356646598993272010-04-17T03:47:00.001-07:002010-04-17T03:47:32.280-07:00Assisted SuicideWhile I normally blog about software development, today I'm going to blog about something much more personal, something that most of my friends probably don't know. The trigger is the debate on the right to assisted suicide in the UK and on the right to access even information about <a href="http://www.exitinternational.net/">assisted suicide in Australia</a>, which would be blocked by the proposed internet filter. While I won't be as articulate as <a href="http://www.guardian.co.uk/commentisfree/2010/feb/01/terry-pratchett-alzheimer-assisted-suicide">Sir Terry Pratchett</a> I want to present my personal experience.<br /><br />I was in my mid-20s when my partner's mother, still in her 40s, was diagnosed with breast cancer. Even though she lived in Cairns, a rural centre, she received excellent care, including flights on the air ambulance to city hospitals when she needed them. That experience, and my own health issues growing up, cemented for me the importance of free national health care, but my brush with assisted suicide came towards the unfortunate end of the story.<br /><br />Despite a radical masectomy and many other treatments the cancer spread to Margaret's bones, and eventually she deteroriated quite rapidly. One day we got a call that if we wanted to see Margaret alive we needed to come to Cairns, right away. My partner was in Melbourne, I was in Sydney, one of my partner's siblings was on a prawn trawler in the Gulf of Carpentaria, but we all dropped what we were doing and went to the airport. I remember walking out of the office, telling my boss that I was leaving right away and I didn't know when I would be back, and him simply replying "Ok, do what you need to do" (thanks for that Brian).<br /><br />We all arrived in Cairns and started a vigil by Margaret's bedside. She was immobile - her bones were so weak and brittle that the nurses needed to be careful not to break them when they changed the bed - she had difficulty breathing, and she was very weak, but she lingered. She was pleased to see all her children, but it was obvious that she was unhappy and she was not going to get better. One morning she told us, in short breaths, that it was impossible to hold your breath until you died - she'd tried it the night before and it didn't work.<br /><br />Margaret had been estranged from her husband before the cancer got very bad, but they had moved back in together to look after her and their youngest child, who was about 12. He was pretty rung out and wasn't really part of the decision-making around Margaret at the time. He was a diagnosed manic-depressive and we were concerned that he might commit suicide after Margaret died, so we talked about how to handle the care of the youngest child in those circumstances. We also needed to talk to Margaret about formalising her will (if you haven't, please do that now, as handling it on your deathbed is no fun for anyone). As the older partner of the oldest child, some of the responsibility for these things rested with me. Eventually the conversation also came around to Margaret's death. It was clear that she was ready to die, from both her actions and her words, and we could see that she might ask one of us to help her. What would we do? What would <strong>I</strong> do?<br /><br />I don't know what everyone else thought. I think we talked about it without making any final decision as a family, but I also know that I made a decision in my own mind. If Margaret asked me to help end her life I would do whatever I could to help. I would do it with tears in my eyes (like the ones I have in my eyes now, writing about this more than 20 years later), but I would do it nonetheless. And it would be illegal, and I would bear the consequences - the legality or otherwise of the action made no difference to the decision and the act, though it might have made a considerable difference to my life. <br /><br />Margaret peacefully and quietly passed away one night in her sleep, with her eldest daughter at her bedside.<br /><br />Assisted suicide isn't a theoretical issue for me, it's a hard, practical one that I faced head-on, and having made that decision once I know that if the circumstances arose again I would make the same decision. I believe that as a caring and compassionate society we should be able to extend the right to die with dignity at the time (and if possible the place) of our own choosing to everyone. I believe that the benefits of providing that right outweighs the cost and effort of monitoring to make sure that the right is not abused.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-5810327852208300742010-04-14T03:26:00.001-07:002010-04-14T03:26:49.379-07:00Quality - I wish we'd be a little more preciseMany years ago I worked at Bankers Trust Australia, building derivative product applications with VMS Cobol for the user interface and Fortran for the numerically intensive parts. I mention the technology so that you can understand that this was the early days of the derivatives markets when there were only a few players in Australia, using relatively unsophisticated technology. I remember how proud we were of the first release, particularly of the way we validated all the user input and provided field-by-field feedback to the traders. Then I was lead into a trap.<br /><br />"Wow, that validation is really impressive. It must have taken you quite a while to do that", said a trader.<br /><br />"Yeah, it probably took a few weeks to get it all right", we replied.<br /><br />"So you could have delivered it a few weeks earlier if you hadn't done that?"<br /><br />"Yes, but the application would have crashed each time you made a mistake and you'd have had to start again", we said.<br /><br />"We're pretty smart, and we can learnt to deal with that. Next time we'd rather have the features two weeks earlier so we can make some money from them thanks".<br /><br />The underlying problem was that we hadn't talked to them about what was important (my excuse is that it was a long time ago and I was young and naive), but the lesson has stuck with me. In that situation, an input function vomiting it's guts on the screen was a <strong>scope</strong> issue, not a <strong>quality</strong> issue. In the years since I've regularly heard people say "we cut quality to go faster" or "we cut quality to finish earlier", but when I dig deeper I invariably hear that they altered the behaviour from the end-user perspective, and to me, a developer on a software project, that's cutting <strong>scope</strong>. I appreciate that other people with different perspectives might consider these features to be the difference between a high-quality or low-quality application, so when we start talking about "quality" we probably need to clearly understand which perspective we're talking about.<br /><br />I was reminded of that by a<a href="http://blog.objectmentor.com/articles/2010/04/06/20-more-bugs-or-20-less-features"> recent post by Uncle Bob</a> that starts with "People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid.". I think that would be stupid, but what I think people mean is that the internal quality of the code has been sacrificed to reduce initial time to market, which is a very different proposition.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com3tag:blogger.com,1999:blog-1554986873086232138.post-67390690778607507542010-03-31T23:13:00.001-07:002010-03-31T23:13:02.577-07:00The end of passionI'm supposed to be doing my US tax return right now, but I got distracted (what a surprise) and read <a href="http://jamesshore.com/Blog/Stumbling-Through-Mediocrity.html">this post</a> from March 2009 by James Shore. At the end of the post James says two things that resonated strongly with me:<br /><br /><blockquote><br /> "If the point is to Be Agile, there's no need for Agile to actually work."<br /></blockquote><br />and<br /><blockquote><br /> "Starting now, I'm reorienting my business to focus on people who want to be great."<br /></blockquote><br />Last night I said goodbye to me colleagues at <a href="http://www.cogentconsulting.com.au">Cogent Consulting</a>, and one of the things that I <strong>meant</strong> to say but forgot was that for me interesting agile consulting work in Melbourne is now rare. I would have struggled to say why until I read James' post - I think it's that once-upon-a-time my consulting work was mostly with people who really wanted to be great, regardless of their current performance. It might not have been everyone in an organisation, but in each organisation it was <strong>enough</strong> people that greatness was the dominant theme. At some point those gigs dwindled - on the new gigs some people may have wanted to be great, but the team/division/company as a whole wasn't really interested. They pay lip-service to greatness, but it's the "we want to be great so long as we don't need to change too much of what we do" variety. My drive is to help people be great, and as that work has withered so has my passion. I may be willing to do work I'm passionate about for peanuts, but I think there's a thread in my mind which says if you can't give me work I'm passionate about then show me the money (and I think that makes me, well, human).<br /><br />Now my soon-to-be-colleagues in Goldman Sachs may read this and shake their heads, so I need to be clear. I've always felt that <strong>enough</strong> of the people at GS wanted to be great to make working there worthwhile. It would be naive to think that it's everyone, everyday, but in my experience it's definitely enough. So I hope to have the pleasure of having my passion rekindle there as well.<br /><br />I think this reinforces Cogent's recent decision on medium-term focus as well. The future of Cogent Consulting <strong>isn't</strong> to help other people with their agile transitions. The future is to blend Cogent's passion for software development with the needs of people who are passionate about their own domain, outside of software development. The result will be delivering excellent solutions that change people's lives - sometimes because no one else could do it economically, sometimes because no one else could build the partnerships that Cogent could build, and sometimes because no one else could do it at all.<br /><br /><strong><br /><blockquote><br /><p>Helping people transition to agile development - 10 years<br /><p>Forming my own consulting company - 2.5 years<br /><p>Finding outlets for my passion - a lifetime<br /></blockquote><br /></strong>Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-74154970464819192762010-03-24T21:27:00.001-07:002010-03-25T22:54:16.468-07:00Who Am I?<strong>** Updated 26/3/2010 **</strong><br /><br /> If you read this blog regularly then you will know that I'm about to embark on a career change. Part of this will be moving from a relatively safe environment where I have a reputation (Melbourne) to a challenging environment where I'm a relative unknown (London). When I meet new people in London (professionally) I'd like to have something I can point people to that gives them some background and helps to set their expectations. I'm personally expecting to be meeting quite a few new people, and I hope that this can accelerate the familiarisation step a bit.<br /><br />First, I'm incredibly introverted. I've learned to be vocal in some situations, but sometimes that confuses things because people don't notice just how introverted I really am. How does that manifest?<br /><br /><blockquote><br /><br /><ul><br /><li>I'm pretty quiet in meetings<br/><br /><br />Particularly if I don't know all the participants I tend to listen more than I speak. That doesn't mean that I'm not thinking about the matter, or that I'm not interested, it just means that I'm not talking :-)</li><br /><br /><li>I think slowly<br/><br /><br />Sometimes experience gives me intuitive leaps, but I'm often the person who comes back the next day and says "that thing we talked about yesterday isn't going to work, and here's why". Even when my intuition gives me the right answer quickly it can still take me a while to come up with an explanation. When this happens it's not that I'm being uncooperative and trying to work outside the meeting/collaboration, it just means it look me a while to get to where I was going </li><br /><br /><li>I understand pairing gives better development results, but it doesn't come naturally to me</li><br /><br /><li>I'm unlikely to join you at the pub for a beer</br><br /><br />It doesn't mean I don't like you, but it's not an environment that suits me.</li><br /><br /><li>I'm not into public celebrations<br/><br /><br />This can get me into trouble, especially when I'm meant to be "leading". It's not that I'm opposed to celebration, it's that it's not something that I volunteer for. If you happen to suggest my team needs one I'm likely to agree and ask you to arrange it!</li><br /><br /><li>I don't deal well with conflict, particularly if it happens quickly</li><br /><br />I'm pretty analytical, but emotions can be a bit tricky for me. I need to gear myself up for situations where there might be conflict, and if one springs upon me unexpectedly I'll usually disengage. It's nothing clinical (empathising comes fairly easily to me), but it is something I've learned about myself.<br /><br /></blockquote><br /><br />I've managed to add a few layers to this introverted foundation. I'm a reasonable public speaker, I generally enjoy it, and I'm happy to talk about software development to any group that's interested.<br /><br />I've been referred to as a "code quality freak". My attitude is that you should work on the micro-level details of programming until they've become muscle memory, so that you can free your brain up to work on the complicated stuff. This covers all the stuff you'd find in coding style guides and books like Bob Martin's Clean Code (though I have to fess up that I haven't read that yet). Even at the micro-level I like to use tools to tell me where I've let me standards slip, so I'm keen on tools like Simian, Checkstyle, Complexian and their equivalents in other languages. These days I'm also interested in visualisation of the output of these tools, though I don't have as much experience in that area.<br /><br />Another metaphor I use around code quality is that it's like hygiene in a hospital - we shouldn't need to talk about it, we should just do it. If we can't maintain hygiene then everything else is going to get a lot, lot harder. Some people suggest that you can clean up your technical debt by having dedicated iterations - to me this is like suggested we let crap pile up around a hospital and clean up every couple of weeks. It doesn't work for me.<br /><br />I love automation. I have a very small brain and I'd rather use it for processing than storage. Manual processes are slow, tedious and error prone - I want to get rid of them.<br /><br />I don't think that software development is predominantly a technical problem, I think that in most cases it's a social problem - how to we organise the people and technology we have to delivery an effective solution as cheaply as possible. Commercial constraints demand creativity and make software development challenging.<br /><br />I like agile practices and processes, but they are means to ends. I think that as humans we are all imperfect - we should accept that we make mistakes, but try to reduce the consequences of our mistakes and try not to make the same ones over and over again. We can continually improve, but to do that we need to continually reflect and continually learn. I'm very keen on the ideas emerging around expertise and deliberate practice.<br /><br />I'm sure I'll think of more and extend this post, but there's a start :-)<br /><br /><br />Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-10721819348162213362010-03-02T02:31:00.001-08:002010-03-02T02:31:18.246-08:00Seven Norms of Highly Powerful Software TeamsI found this, a handwritten copy no less, while cleaning out a filing cabinet tonight. At the bottom I've written "Charlie Alfred, Education Services Manager, Object Design Inc, Object Magazine, May 1994". Apparently I've been carrying this around for almost 16 years. Since Google didn't find the article, I reproduce here for your pleasure (and so I can find it again myself).<br /><br /><h2>Affinity for win/win</h2><br /><br />We strive to create an environment where the personal aspirations of each team member contribute to the goals of the team. We each are personally committed to achieving the goals of the team without sacrificing our lives outside work. We firmly believe that on the strongest teams the goals of the team agree with the goals of its members, rather than supersede them.<br /><br /><h2>Common Mission</h2><br /><br />We share a common mission that is challenging, worthwhile, and clearly understood by all. This mission may be perceived by others as impossible or not worth the sacrifice. In this way, the mission helps us to identify our partners. Also, the more impossible the mission seems, the more we are forced to work together if we hope to succeed.<br /><br /><h2>Quality</h2><br /><br />Quality is at the core of everything we do. If something is worth doing at all, it is worth doing right the first time.<br /><br /><h2>Understanding Requirements</h2><br /><br />We strive to fully understand the requirements of the systems we plan to construct, including being acutely aware of how those requirements evolve over time. Furthermore, we actively validate our understanding of these requirements with the system's intended beneficiaries.<br /><br /><h2>Interdependence</h2><br /><br />Individually, we each contribute strengths that counterbalance each other's weaknesses. Collectively we possess all of the skills, attitudes, and habits necessary for team success. Wherever an essential skill, attitude or habit is missing (or lacking), one or more of us makes it a priority to develop it, or we seek to add a new member who possesses it.<br /><br /><h2>Receptivity</h2><br /><br />We are open to sources of new ideas and new ways of doing things, and use the norm to resolve conflict. We listen to each other's points of views, aware that our commitment to the same mission means that differences of opinion identify alternate paths to the same goal rather than competing paths to different goals. Also, we continually learn about and apply the latest paradigms, processes, and products in our technical, organisational and interpersonal activities.<br /><br /><h2>Efficiency</h2><br /><br />Around here we work smarter, not necessarily harder. We sprint all out toward our goals when it is necessary to do so, but also know how to relax and rejuvenate. We make the 80/20 rule work for us. We take no shortcuts and cut no corners on the 20% of our tasks that produce 80% of our results. If any sacrifices must be made (in the interest of time), they always fall in the 80% of our activities that produce 20% of our results.<br /><br />Thanks Charlie!Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com1tag:blogger.com,1999:blog-1554986873086232138.post-16445583400356803652010-02-25T22:41:00.001-08:002010-02-25T22:41:45.865-08:00Netflix CultureMany of you may have seen this already, but if you haven't I think it's an essential read. <a href="http://www.slideshare.net/reed2001/culture-1798664">"Freedom and Responsibility Culture"</a> describes how Netflix resolves the challenges involved in growing rapidly while maintaining a culture that supports rapid innovation and excellent execution. It's a good explanation of why they don't adopt the process-bound, complex-compensation approach that I see at many organisations. Some of what they do is consistent with what we do at Cogent, but some of it is radical even for me (for example, there is no vacation policy!). I wish I had read it earlier.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-37757314874857817652010-02-15T14:09:00.001-08:002010-02-15T19:12:27.280-08:00Cogent Departure, Part 2In an earlier post I mentioned that I'd pass on more details of my Cogent departure as they became available. I'm at that point now, but before I can tell you that story, I have to tell you <strong>this</strong> story (a tribute to my 6y.o. son's Captain Underpants fandom, which is another story altogether).<br /><br />Twenty years ago, come March, I moved to London. It was the height of Thatcherism, and shortly after I arrived I went to a matinee at the theatre. At the end of the performance someone came on stage to say there had been "a bit of bother" and we should avoid Trafalgar Square. As an ignorant new arrival I didn't know how to do that, so I ended up walking through the debris of the <a href="http://en.wikipedia.org/wiki/Poll_Tax_Riots">Trafalgar Square Riot</a>. Welcome to London, Mr Hayes! London is an amazing place, with deep history and so many things to see, but the next year is tagged in my mind with impressions of tension and antagonism. I've visited since and found London to be far more pleasant than it was in 1990.<br /><br />Ten years ago I was working at Goldman Sachs in New York. I was leading one of the best development teams I have ever had and we were implementing XP on a full project - a first for me and a first for Goldman. Early the next year I did something very un-Goldman - I resigned. I used my bonus to pay off my last debt (the mortgage on my house in Sydney), Amanda and I travelled around America (20,000 miles in just over 100 days), then we moved to Melbourne and did as little as we needed to to cover the rent. There were about 6 people in Thoughtworks Australia doing "agile", but they were working remotely on the Caterpillar project, and that was it. I spoke to as many groups as possible about XP, and things grew from there. Essentially this was the beginning of the path that lead to Cogent Consulting.<br /><br />This year I'm going to complete some decade long cycles. The current plan is to return to both London and Goldman Sachs, as EMEA Controllers CTO (EMEA is "Europe, Middle East, Africa", but from a technology perspective that's Europe). Before anyone gets excited, there are lots of CTOs in Goldman Sachs - I think I'll be responsible for technical direction for about 0.5% of the banks IT staff, and I'll be in a matrix with many other architects. Regardless of scope, I think this is a great opportunity for me and will be a great experience for my family. We're tentatively scheduling a move in April, but plans are on hold pending the tabling of financial services legislation in London that may impact GS staffing. I still plan to finish up with Cogent at the end of March and to take some leave if there is time. <br /><br />On the other hand, my infrequent blogging and twittering will probably become almost non-existent. GS holds things very close to its chest, now more than ever I expect, and is very careful that random technical comments don't get associated with the GS brand (for either better or worse). Since I'm an expert in random comments I'll need to watch my mouth fairly closely. :-)<br /><br />If you're in London and you'd like to catch up later in the year please let me know - part of this opportunity is the chance to renew (and create) relationships in the northern hemisphere!<br /><br />PS. Some people have read this and wondered why I would move to a job in management. At GS architects at all levels code 80% of the time, so if anything I'll be doing <strong>less</strong> management than I do at Cogent and in my current consulting roles. I suspect a lot of it will be up to me. I still expect to have plenty of opportunities to influence behaviour.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com9tag:blogger.com,1999:blog-1554986873086232138.post-51351940295961415592010-02-08T17:25:00.001-08:002010-02-08T18:45:47.233-08:00Why Post-Agilism isn'tI have a strong dislike for the term "post-agilism" and it will take somewhat more than 140 characters to explain why. Sorry twitter.<br /><br />Post-agilism is a strawman argument. It postulates that agilism is zealous, doctrinaire and narrow-minded, and then posits that because of these deficiencies we need something that is "post-agilist". Implicit in this is that people who call themselves "agilists" have got it wrong.<br /><br />This is simply another turn in a vicious circle. The "post-agilists" solution is a restatement of agile principles. Agile didn't start with hype, it didn't start with zealotry. On the contrary, Agile by declaration is adaptive and focussed on getting working software delivered. If you say you're doing agile but you don't believe in these principles then I'm sorry folks, you're just wrong. You probably weren't there at the beginning, and you've been misinformed, quite possibly by people who cherry-picked things out of context. We don't need another revolution, we need help with the swinging pendulum of the current phase.<br /><br />So for the "post-agilists" out there - change your message. Say "wow, lots of people are doing agile wrong, we need to stop that, let's do agile right". Otherwise in 10 more years we'll have post-post-agilists decrying the shortcomings of how people have interpreted post-agilism (though more likely because of a lack of any structure than from too much). Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-53402074550380724872010-01-26T22:26:00.001-08:002010-01-27T19:51:11.939-08:00Cogent DepartureWith sadness and trepidation I need to tell everyone that I plan to leave Cogent Consulting. I appreciate that you're not supposed to leave your own company, but I've rarely let what you're "supposed" to do govern my career. My departure from Cogent will create a hole, but I'm perfectly comfortable that the hole will be quickly filled. Marty Andrews will take over my role as decision-maker-of-last-resort, and I expect that most people, both staff and customers, will notice little difference on how Cogent runs or the quality of the service that it provides.<br /><br />The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".<br /><br />I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.<br /><br />In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.<br /><br />I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com3tag:blogger.com,1999:blog-1554986873086232138.post-51060440434343714862010-01-07T21:33:00.001-08:002010-01-07T21:33:49.530-08:00Waste that we watch for<ul><br /><li>Partially Done Work<br /><li>Relearning<br /><li>Hand-offs<br /><li>Task Switching<br /><li>Delays<br /><li>Defects<br /><li>Extra Features<br /></ul>Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com1tag:blogger.com,1999:blog-1554986873086232138.post-63326970262368780322010-01-07T21:32:00.001-08:002010-01-07T21:32:29.866-08:00Cogent PrinciplesJust in case you're interested :-)<br /><br /><ul><br /><li>Feedback over Technical Elegance<br /><li>Reliability over Feedback<br /><li>Relationships over Code<br /><li>Learning over Producing<br /></ul>Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-6173598702458462232010-01-06T21:17:00.001-08:002010-01-07T01:22:59.628-08:00Are we there (agile) yet?I get asked this a lot, and let me say that I personally don't care very much. I do care whether or not the development process is effective or not, and mostly you know the answer to that before you ask me. But if I needed to form an independent opinion here are some questions that I'd ask you about feedback cycles. The underlying assumption is that a team will almost continually make mistakes (that vary dramatically in size) and that a lot of our practices and processes are about exposing those mistakes as quickly as possible. So how long is it between the these mistakes and the practice/process/activity that will expose that mistake, and how do you make that period smaller? These questions aren't presented in any particular order.<br /><br /><ul><br /><li>A feature doesn't add any value</li><br /><li>Our code is unmaintainable</li><br /><li>We have duplicate code (or other quality problems)</li><br /><li>A developer introduces a new defect</li><br /><li>We've broken an existing feature</li><br /><li>What we're building doesn't match what was expected</li><br /><li>A feature is costing too much to be worth implementing</li><br /><li>A feature is unusable</li><br /><li>A feature works in isolation but not when integrated with other features</li><br /><li>The entire project is costing too much</li><br /><li>The project is going to cost too much</li><br /></ul><br /><br />In addition, how long from a the time a feature is requested to the time that it hits production?<br /><br />There are certainly other things that can go wrong with a project, but I think that reducing feedback cycle duration (time between event and feedback on the event) requires applying many agile principles and practices.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-81444248121458230992009-12-08T02:59:00.001-08:002009-12-08T02:59:59.663-08:00Should we lower quality to go faster?Here's an email from one of our consultants, and my response (edited for anonymity and to removing the internal cursing!).<br /><hr><br /><br />So, our product manager asked me today whether we could (just) let quality slide for a while, in the interests of getting stuff done faster.<br /><br />I gibbered and muttered for a bit, and then gave an answer which amounted to "I don't know how to do that". Which is true; having personally experienced the benefits of practices like pairing, automated tests, and refactoring, and having done things that way exclusively for a quite a while, I'm not sure I know HOW to do it the old way.<br /><br />I'm not sure that the his concern has gone away, though. He describes his experience as "mostly startup-like stuff", throwing stuff together quickly, and potentially throwing in away a few short years later. He's certainly never worked in an agile environment before, and is doubtful about the value of some of our practices.<br /><br />Any advice?<br /><hr><br /><br />As with most companies with a history of software development, there are people who have been burned by non-agile development, and people who haven't had that experience, and they have very different perceptions.<br /><br />Here are some principles:<br /><br />1) The customer is in control of the quality sliders for a project. We (IT, not just Cogent) are a service provider who give advice and recommendations, and then act on the instructions/direction of the business.<br /><br />2) If the customer asks us to do something we (Cogent) fundamentally disagree with, we tell them that we are not the right group to provide that service and we quietly, respectfully disengage. Think of a surgeon who was told to perform operations without sterilisation, and that someone else would deal with the infection later.<br /><br />3) There certainly are times when "not doing things the right way" is appropriate. I wrote the first cuts of Cogent Times with no test cases, because I didn't know if it would get any traction (i.e. be useful enough for people to use it). I don't regret it, and I would do it that way again. Now I'm adding test cases incrementally. When Runway was only developed by Simon it didn't have tests either - we demonstrated that this didn't scale. Kent's blog on the <a href="http://www.threeriversinstitute.org/blog/?p=251">Flight of a Startup</a> describes this well.<br /><br />4) I think it's important to understand timeframes though. I believe that letting (internal) quality slide for a while will get stuff done faster for a few weeks. Other people seem to think that it will let them go faster for months or years. I disagree. Put simply, dropping quality won't get things done faster. We have the courage of our convictions here - we use these practices when we spend our own money on our own applications, when we really, truly, want to go as fast as we can.<br /><br />5) The impact of lower (internal) quality is exacerbated by:<br /> number of people working on the application <br /> quality of the people working on the application<br /> size of the application<br /> level of understanding of the problem domain<br /> level of change in requirements<br /> flexibility of the technology stack<br /> tolerance for defects in production<br /><br />If your application is being built in a modern language, by one skilled person who is familiar with the product domain, working with people who know what they want and can describe it in detail without hesitation, false starts or iterations, and no one loses any money (or lives) if there are production defects, then what we do is definitely overkill. I've yet to see an environment that matches this description.<br /> <br />Having said all that, in the bigger picture the product manager isn't necessarily the person who makes the decisions on where the quality sliders are. Those are frequently decisions that need to be made at a higher level as they affect the total life cycle cost of the application, and the product manager is only responsible for the development part. This is the classic breakdown mode of process change - the people who bear the cost of the process change are not the people who reap the benefits of the product change. Producing a stable, defect free application that can be extended isn't necessarily in the product manager's interest, though it may very well be in the company's overall interest, especially when funding is allocated per project rather than per product. I present that argument mostly for completeness, since I think that the payback period of our practices is short enough that they're in the product manager's interest as well.<br /><br />Things get even worse when the organisation funds work as "projects" rather than investing in "products". In these situations the value of feedback is reduced (since success is judged on the delivery of the promised features) and the focus is on the short term (the delivery phase for those features).<br /><br />However it's also fair for the customer (and I mean the big-picture customer, not just the product manager) to suggest experiments - a good question in those situations is what will be measured to determine if things are better, and better for who? You need all the stakeholders involved in these discussions, not just the product owners.<br /><br />Also bear in mind that we are not the only people to say these kinds of things. I believe part of what you're seeing is descent into the "easiest" possible implementation of Scrum. Here's what they're implicitly asking for:<br /><br />"To be able to change their mind on requirements each iteration, and to obtain the benefits of this flexibility, without either performing enough up-front analysis to understand the fundamentals of the problem domain, or making any investment in the technical robustness of the application to support change"<br /><br />This is very appealing from a business perspective, but it's an illusion. Jeff Sutherland has said he's never seen a hyper-productive Scrum team that didn't use the XP technical practices. Martin Fowler has written on what he calls <a href="http://www.martinfowler.com/bliki/FlaccidScrum.html">Flaccid Scrum</a>. The trend is to no longer consider the practices you mention as "agile", but simply "contemporary" - things you should be doing without a second thought.<br /><br />So my first response to these kinds of suggestions (actually, my second, after I stop cursing) is that if the proposals would make things go faster then we'd happily implement them. But they won't. If I'm challenged further then I would ask them to find someone else on the <strong>technical staff</strong> who believe that the proposals will make things go faster, and then I'd step aside for them.<br /><br />Seriously, hospital administrators don't tell surgeons how to maintain hygiene and where to cut. The customer can do whatever they want - we don't have to do it for them.<br /><br />Not sure if that helps or not.<br /><br />Steve<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com7tag:blogger.com,1999:blog-1554986873086232138.post-50756313331383620602009-10-19T16:36:00.001-07:002009-10-19T16:36:47.859-07:00Roles in a self-organising teamOne of the things that I'm asked to do fairly regularly is define the roles for an agile team, be it for Scrum, XP or some other flavour of agile. I usually end up doing this based on required skills, but my first impulse is to refuse, because I don't believe that a self-organising team actually has roles and I think that defined roles limit both the individual and the team. Let me examine that point before I explain how I do go about defining roles and why.<br /><br />There is one role on a self-organising team - team member. The responsibility of that role is to bring all their skills to bear on the team's problems and organise their contributions to maximise the team's effectiveness.<br /><br />When something needs to be done on an agile team everyone on the team should be able to see it, and in many cases it will be obvious which individual or individuals are the best suited to getting it done. The simplest approach is to allocate tasks based on skills, but the team might decide to use other criteria as well - they may need to grow their capacity in some area and decide to give the task to someone with less experience to give that person some practice; they may have limited capacity and be forced to give the task to someone who needs to learn the required skill, usually with mentoring from someone on the team. There will also be team-specific and project-specific reasons for not allocating tasks based simply on skill set. The important thing is that the reasons are well-articulated, and that the team member accepts responsibility for the task rather than having it arbitrarily assigned to them.<br /><br />Although multi-skilled teams are normal and effective, provided the team is dedicated to achieving a result, has sufficient time and is reasonably self-aware you can imagine any arbitrary skills starting point. We could take a team that consisted entirely of testers and give them some work to do. The first tasks they encountered would require some analysis, so someone from the team would need to do this. They wouldn't complete the analysis as quickly or to the same quality as someone with the relevant experience, and they might not enjoy it as much. They might also need to get outside expertise (training and/or mentoring), but they would get through the work eventually. The team might find someone who wanted to grow into this role and make them the primary analyst, or they might decide that no one enjoys it and the role should be rotated through the team (this is probably less efficient, but it explicitly ranks satisfaction and retention ahead of efficiency). The same pattern can be repeated with development and anything else the team needs to get done.<br /><br />Don't get me wrong - this is clearly a slow path to success and I wouldn't recommend it, but it is a valid approach. It's a contrast to the behaviour I see more often, which is "I can't do X, because I'm a Y". "Can't" is definitely the wrong word - finding the right word will determine how you respond to this assertion. If the person is really saying "I don't like doing X" then keep the assignment short and try to find some other way to make it attractive. If they're saying "I don't know how to do X", then they need training, guidance and support. If they're saying " I won't do X" then they probably shouldn't be part of the team.<br /><br />That's why I don't like roles - why do I provide descriptions of roles and responsibilities? It's because I would rather start with a team with diverse skills than spend a lot of time developing the same skills, and most organisations understand that as a request for roles. I also appreciate that most people have gravitated towards a role that suits their preferences and skills, and asking people to move into other areas requires both time and motivation that we usually don't have a the beginning of project.<br /><br />My hope is that companies that go to the trouble of assembling multi-discipline teams will also recognise the benefits of keeping those teams together for long periods of time. Time is the essential ingredient to building role-independent teams - it helps build trust between the team members, it lets people experiment and learn, and it gives the team opportunities to get feedback on different approaches to task assignment.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-87363270354473951992009-10-13T21:34:00.001-07:002009-10-27T16:13:09.019-07:00An interesting exchangeI wrote this in response to a customer email, but it seemed like something that I could put here:<br /><br />On 14/10/2009, at 9:15 AM, ... wrote:<br /><br /><blockquote><br />Morning Steve,<br /> <br />Saw this article and thought it was interesting. http://www.javaworld.com/community/node/3530<br /> <br />Regards<br />...<br /></blockquote><br /><br />From: Steve<br /><br /><blockquote><br />It is interesting. I think it's hard to get the tone right when you're dismissive of agile zealots (who it's hard to agree with, almost by definition), without being dismissive of agile in general. Having been involved with agile for a long time I have a nice clear centre that tells me that agile should be adaptive, but I've also seen the problems that come from being too adaptive too early.<br /><br />I totally agree that the process for one or two really talented, motivated people is different from the process you use for larger groups/applications. Alistair Cockburn has been very explicit about this in his writing about the Crystal family of methodologies, and Kent Beck has touched on the same subject from a different perspective when he wrote his blogs about "Flight of the Startup". The hard part for most of us is dispassionately looking our our team and ourselves and changing process over time. It's easy to err on the side of too much, too soon or too little, too late, but very hard to judge it just right.<br /><br />On the "where's the Access of today", that's a question that we've thrown around within Cogent as well. My personal opinion, shared by some others in the company but not everyone, is that we've gone backwards over the last 10 years in productivity and our ability to deliver things quickly. Our capabilitity has increased - we can deliver bigger, more sophisticated applications - but in the process everything seems to have become harder.<br /><br />I agree with the poster who mentioned the combination of Ruby on Rails and Heroku - that's the combination that I'm using for my personal projects now. I think it's the combination that's the winner - there are other frameworks that to me look more promising than RoR but with each of them I have to manage my production environment myself (for some of them even setting up a production environment is a challenge). Heroku takes care of that and make deployment as simple as possible.<br /><br />On the OS X desktop MacRuby looks very promising, leveraging Inteface Builder with the power of Ruby. I don't play in the Windows space, so I don't have any idea what the possibilities are there.<br /><br />...<br /><br />Steve<br /></blockquote>Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-71346436214653550042009-10-07T17:07:00.001-07:002009-10-07T17:08:25.404-07:00My Kindle DX and II've fielded more questions about my Kindle, and how I use it in Australia, than just about anything else I've mentioned on Twitter so I thought I'd put the information in a blog post.<br /><br />After October 7 this information is really only useful if you want a Kindle DX - if you're happy with the smaller Kindle then you should buy an internationalised version and avoid all the issues I'll describe.<br /><br /><h2>Why a Kindle?</h2><br />Books are heavy, and I often want to carry around more than one for reference, especially if I'm doing some writing. At lot of the things I want to read these days are also in PDF and I haven't found a good way to read those - I end up reading a lot either on public transport or just before bed and my laptop isn't convenient in those environments. I tried using my iPhone to read PDFs but that doesn't work for me (other people seem very happy).<br /><br />The Kindle is great for reading material that's been formatted for the device - I haven't found it to be that good for PDFs (more on that later). It's much better for me than either my laptop or my iPhone. The screen has great contrast, a huge viewing angle, and when I first opened the box I couldn't believe the starting image was being displayed on something electronic.<br /> <br /><h2>First Problem</h2><br />The first problem is that Amazon won't sell you a Kindle DX if your shipping address is outside this USA. My first solution was to have one shipped to a friend in the USA and then shipped on to me, but it turns out that there are people on eBay who can help. My KIndle DX arrived in the original Amazon packaging, with the original seals intact, with a new shipping wrapper pasted over the original.<br /><br /><h2>Charging </h2><br />The Kindle arrives with a USA style power adapter, but the approach is the same as the iPhone - it's a USB connecter that plugs into the adapter. Since I already have an iPhone charger I can plug into that, or I can charge from my computer.<br /><br />The Kindle is fairly frugal with power. Since you won't be using WhisperNet you can turn off the wireless connection to reduce battery use. The screen is bi-stable, so it only uses power when you move from one page to another. I charged my Kindle last Friday night - it's currently Thursday morning and I'm still using it happily.<br /><br /><h2>Content</h2><br />Amazon (who I'll get to later) isn't the only source of content for your Kindle. You can use .mobi files from other sources, or PDFs. For example, I buy combo packs from the Pragmatic Programmers, so I have .mobi versions of all of their books, and their magazine comes out in the same format.<br /><br />If you want to buy content from Amazon you won't be able to do it with an Australian credit card/address. I've set up a separate Amazon account for my Kindle purchases and given it my old Brooklyn address (you can use that too if you ask me nicely). I buy an Amazon gift voucher on my Australian account and then use the gift card to buy the content on my Amazon Kindle account. It's an extra step, but it's not really that much of a problem. I download the content to my laptop and transfer it to my Kindle via USB (the Kindle looks like any other disk drive).<br /><br /><h2>Carrying an extra device</h2><br />Yes, it's one more device, but I've put my Kindle in the back pocket of my backpack and I really don't notice the extra weight at all. It's always there if I want to read, and I use it with one hand even if I'm standing on public transport.<br /><br /><h2>Summary</h2><br />There's no economic reason for me to have a Kindle, but I'm really enjoying the experience. The proof of the Kindle pudding will be how it scales to having the majority of my library on a device I carry around with me. I suspect that this will change the way I treat information.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com4tag:blogger.com,1999:blog-1554986873086232138.post-92005908393293833632009-10-05T16:56:00.001-07:002009-10-05T16:56:43.468-07:00Ubiquitous LanguageBusiness language is a pain in the ass. People are way too smart and capable of dealing with ambiguity, and the more familiarity they have with a particular domain the more ambiguity they can handle. They use multiple words for the same thing (perhaps with subtle differences between the words, perhaps not) and they simultaneously use the same word for different things. If you're not "in the know" it can be very confusing. Worse, it may be confusing the people who *are* in the know - the loose language may be obscuring inconsistencies that only become clear when you try to apply automation (computers aren't as tolerant of ambiguity as people are).<br /><br />There have been multiple attempts at dealing with this problem. Once upon a time it was common to say that business analysts were translators, responsible for taking things that the business understood and turning them into things that the developers understood. Of course this involves waste, in the form of hand-offs and delays, and inevitably introduces defects.<br /><br />Extreme Programming introduced the idea of a <a href="http://en.wikipedia.org/wiki/Extreme_Programming_Practices#System_metaphor">System Metaphor</a>, but most people find it hard to come up with an appropriate metaphor for their application. When someone mentioned this to Martin Fowler at a conference he said "Oh, we just use the naive metaphor" - that is, the developers used the language of the business.<br /><br />Other people use different words for the same idea - <a href="http://c2.com/cgi/wiki?SystemOfNames">System of Names</a> for example. <a href="http://en.wikipedia.org/wiki/Domain-driven_design">Domain Driven Design</a> also has this idea at its core. However, the most common term for this idea is <a href="http://www.emxsoftware.com/Domain+Driven+Design/DDD+Ubiqitous+Language">Ubiquitous Language</a>.<br /><br />Ubiquitous language means that <strong>everyone</strong> in the team is using the same language for the same things - mainly business concepts, but if there are important technical concepts these should be part of the language as well. The language also needs to be precise - coming up with ubiquitous language often requires disciplined analysis from a number of stakeholders (ubiquitous language does not come from one person working in isolation).<br /><br />Normally we ask a team to converge on one set of language, but I'm currently working with a project that involves both a vendor and their customer.The vendor already has a well-developed set of language around their product, and the customers have a well-developed set of language around their business processes. Probably neither set of language meets my definition of a ubiquitous language, but we should try move them in this direction. Reducing them to one set of common language would probably be impossible, so we probably have to live with both sets for the duration of the program.<br /><br /><br /><br /> Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-62792974423002538152009-09-07T23:23:00.001-07:002009-09-07T23:42:35.036-07:00Code Review for GitI wanted to find a way to contribute to projects that I couldn't pair on, and to be able to scan a project for possible changes without sitting down and taking up someone's time. Sounded a lot like automated code review, so I had a look around at available code review tools. There are a few available - <a href="http://www.review-board.org">Review Board</a>, <a href="http://smartbear.com/">Smart Bear</a> and<a href="http://www.atlassian.com/software/crucible/"> Crucible</a> among them. I know Atlassian and generally like their products so I decided to install Crucible and give it a try.<br /><br />There were a few confusing configuration problems. Until I read the documentation more closely (at all?) I wasn't aware that the beta Git plugin only worked against local git repositories, and I had to change a configuration file to convince Crucible that Ruby files should be treated as text instead of binaries, but once I got past these problems I clearly had a powerful tool for distributed, multi-party code reviews available to me.<br /><br />So I created a review, looked at some code, and saw one thing that I would change. I wrote the comment, but things just felt wrong. It had taken me a while to type to comment (I'm not the world's fastest typist, but nor am I the slowest), and it felt like a waste of time. It would have been far faster to make the change and annotate the corresponding commit, but what I had was a code review tool, not an editor. Something wasn't working for me.<br /><br />When I do a code review I want to achieve two things - I want to fix the code and I want to educate someone (where that someone may be me, if I wrote the original code). What I really wanted was something (an editor) that would let me focus on changes between versions, but let me change the latest version and save it. My VCS could store the comments against the (small) changes and I could point people to the VCS history to see what I'd done, potentially using the same tool.<br /><br />After looking at a few different tools last night I've settled on <a href="http://connectedflow.com/changes/">Changes</a>. Changes lets you compare directory structures and files, and it comes with some Ruby scripts that will help you retrieve specific revisions from Git, drop them into temp directories and review the differences. I've modified the script to use the current directory if you're comparing to HEAD, so that changes to the head are saved directly to disk and can be committed.<br /><br />Here's my process:<br /><br />1) Use GitX to determine the revision I want to use as the base<br />2) Use changes to view the differences<br />3) Incrementally work through the files either making changes or excluding the files.<br /><br />I've created a (silent) <a href="http://www.youtube.com/watch?v=Dh6BGFl--Xw">video</a> that shows me working through one review. I only make one small change, so it's mostly scrolling and excluding. One small point - the video uses an older version of my Ruby script that created a temp directory even if you were looking at HEAD, so changes were lost. I've fixed that in <a href="http://gist.github.com/182747">this version</a>.<br /><br />I saw some comments that Changes was rather expensive (US$49.99), but it's really cheap compared to many code review tools so I'm pretty happy with this approach.<br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/Dh6BGFl--Xw&hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Dh6BGFl--Xw&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-87061611824663397712009-08-27T14:11:00.001-07:002009-08-27T14:11:06.113-07:00How I learned to stop worrying and love Enterprise AgileI spent Wednesday at the Software Craftsmanship North America Conference and the evening at a cocktail party hosted by Thoughtworks. It was a very interesting day, and in the evening a chance comment by Ward Cunningham helped dispel a misconception I've held for a decade. For the last ten years I've been conflating agile and what I'll loosely call mastery. I think it's fair to say that mastery helps you do agile <strong>well</strong>, but it's not <strong>essential</strong> to labelling your project agile.<br /><br />So I sat down and tried to figure out what "agile" was from my perspective. There are clearly lots of ways that you can attack that problem, but for the moment I've settled on this - a project is agile if it uses scope as the control variable and incorporates feedback mechanisms to facilitate that control.<br /><br />That's a pretty broad definition, but it helped clear something up for me right away. I've been annoyed by resumes that said "agile experience", because I didn't think the people claiming agile experience met the cut. The problem was that saying "has agile experience" is like saying "has programming experience" - it may be true, but it's not terribly useful. You need a lot more detail before you can form any judgement on the claim - what practices has the person been using, how long have they used them for, can they describe the pros and cons? Almost exactly the kind of information you'd want to have about someone's programming experience. <br /><br />Mastery, on the hand, is about continual learning and improvement, in this case in the agile context. I try to pursue mastery of agile software development, and I prefer to work with people who aspire to be masters, but that's not the only way to approach agile. Most people in any field are not masters, and many do not aspire to be masters in that particular field, but that doesn't mean they won't benefit from understanding and using agile practices.<br /><br />So while I will personally continue to pursue mastery of agile software development, and want that to be the focus for Cogent Consulting as well, I hope to spend more time thinking about how to apply agile development in environments that don't have access to master software developers.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com2tag:blogger.com,1999:blog-1554986873086232138.post-31056068225174595922009-07-28T20:22:00.001-07:002009-07-28T20:22:13.372-07:00Software CulturesI think every programming language (and frameworks too) generates a dominant culture. It might be implicit in the language/tool itself, or it might happen more gradually through self selection. For example, here's how I distinguish three cultures (the boundaries are inherently fuzzy, and I'm aware that this is totally personal opinion, so people are bound to disagree by either raising counter-examples or saying they don't agree, and that's fine). I also have my tongue firmly in my cheek, but I believe there's an element of truth in each statement.<br /><br />Java - a fascination with flexibility, generally achieved through complexity (and a healthy(?) does of XML). Ten years ago I would have said Java was focussed on solidity and reliability (in the meeting expectations sense), but I think this has changed over time. New functionality is implemented by adding new options. If it doesn't work, it's because you didn't configure it properly.<br /><br />Rails - a fascination with bright, shiny new toys. Encourages the image of the developer as a person young enough to live in the code, who can deal with either new tools or tools that fundamentally change every three months or so. New functionality is achieved by implementing a new plugin/gem which needs to be compared to all existing alternatives. No solutions is 100% complete because people lose interest first. If it doesn't work, get in there and change the code yourself. [note - I don't comment on Ruby itself as I don't have enough exposure to the non-Rails community]<br /><br />Seaside - I'm an old-hand in Smalltalk, just learning Seaside. So far I see a fascination with having something that just frackin' works (though it might be heavily engineered). The documentation sucks though, so get into the code. Changes are generally transparent and backwardly compatible. If it doesn't work, you did something wrong - the community is the documentation.<br /><br />Each of these cultures has strengths and weaknesses. I'm 46 years old (shit, when did that happen), my raw memory isn't as strong as it was, and I don't think as quickly as I used to. But I have a load of experience in developing design models and applications - I want tools that get out of my way and let me build things. Given my Smalltalk experience, Seaside is a great match for me - much better than Rails. If there was the equivalent of "Agile Web Development Using Rails" then it would rock!<br /><br />In an age when everyone needs to use portfolio theory to manage their software investments, starting low-cost initiatives by the dozen then abandoning the ones that don't work out, Rails is a clear winner over Java. It lets me experiment at low cost, it lets me get something out-the-door quickly. In that environment Java is a set of leg-irons. But the Rails culture thrives when people have enough time and energy to deal with a firehose of changes and alternatives - as an entrepreneur a lot of this is simply waste. One solution might be to standardise on a particular configuration - that seems like a false.optimisation.<br /><br />Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-86283515033919618982009-07-14T23:27:00.001-07:002009-07-17T17:48:59.835-07:00What would you like in a code quality tool?Although continuous integration has been a huge step forwards for the development community I think that over time we've tended to treat it as a rather large bucket that we could keep tossing things into. Sure, someone should immediately address that method that's too long, but should it really stop the build and the release of the next version if all the tests pass? My feeling is no, it shouldn't.<br /><br />I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that <a href="http://blog.martyandrews.net/">Marty Andrews</a> and <a href="http://www.harukizaemon.com/">Simon Harris</a> have been kicking around for a few years (Marty is the author of <a href="http://github.com/martinjandrews/roodi/tree/master">Roodi</a> and <a href="http://martyandrews.net/resources/complexian.html">Complexian</a>, and Simon is the author of <a href="http://www.redhillconsulting.com.au/products/simian/">Simian</a>, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.<br /><br />We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.<br /><br />We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in <a href="http://www.cogentconsulting.com.au/products/survey.html">our product survey</a>. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com1tag:blogger.com,1999:blog-1554986873086232138.post-32083290007972155772009-07-14T19:03:00.001-07:002009-07-14T19:03:47.066-07:00Cogent plays dress-upsThis is an email that I sent to everyone at <a href="http://www.cogentconsulting.com.au">Cogent Consulting</a> this morning, reprinted here because I think it demonstrates the values that we're trying to pursue (and some other people seem to agree). The background is that we're having an offsite this weekend and one of the staff has asked everyone to 'dress nicely' because there will be a professional photographer to take some staff shots. Unlike most of our decisions, this wasn't telegraphed or discussed in advance. There was some resistance. <br /><br /><hr/><br /><br />I broke my transparency rule yesterday, and let what was for me a considered decision look somewhat arbitrary and without explanation. So, why have professional photos of the staff?<br /><br />First, we're going to be doing more and more work for people who don't know us personally, or even by reputation. The pool of work from people who already know us has shrunk, and the team has grown. Neither of those are bad things - from my perspective they're an inevitable part of time passing. What it also means to me is that we need to be a bit more careful/particular about how we present Cogent as a product/service.<br /><br />Presenting Cogent has lots of aspects. Peter Styles from RedBubble was talking to some people last night while I was on the phone and pointed to me and remarked "these guys can be the Pivotal Labs of Australia". That assessment appeals to my ego, but it's also an interesting guide to projection, promotion and marketing. The Pivotal guys blog a lot, and they produce open source projects - we do some of each, but not as much as we could. I don't put enough emphasis on it myself.<br /><br />Another aspect of presenting Cogent is making the website look "polished". It's hard to put my finger on what that really means, but we all have websites that give us a "wow" factor, even if we'd come up with quite different results if we listed those sites. It's not a single thing that makes the difference, but I think that one thing is having well-presented, reasonably consistent, photos of the staff. It literally stops the company from being a faceless entity. Hence the professional photographer on the weekend.<br /><br />If you stop by the TW office you'll see that they make extensive use of real photos of real staff right in their reception - there's a wall with large scale images, not just snapshots. From memory Evan is reclining in a deck chair working on his laptop :-) I'm not proposing something like that right now, but I wouldn't rule it out in future either - I'm proud of the people in the company and I want them to be the face of the company. I don't want everything to be about 'senior management' as it is in lots of places. We may find other places where putting photos of our staff makes sense - for example, tender documents often list staff, and I think having small photos included in a list like that makes it more appealing (I have this strange idea that saying no to even a picture of a person's face is harder than saying no to a piece of text *s*).<br /><br />Anyway, there's the rationale. If there are people who have personal objections to photos under any circumstances then of course I respect that. If the resistance is because it seems 'corporate' or corny then I'd like you to try to overcome that for just a little while, since I sincerely believe this is helpful.<br /><br />SteveSteve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-69309420361490549862009-06-26T21:36:00.001-07:002009-06-26T21:36:06.188-07:00Emerging Agile UX PracticesI am not a UX professional, but I've interacted with a number of them over the last few years, in the context of agile development. The interaction hasn't always been smooth - the prevailing mood has been that agile development was asking UX professionals to do a bad job, but I've never felt that way myself. My feeling is that UX professionals and software developers have been on similar paths in regard to agile development, but the UX people are starting a few years later and have had less leadership so their challenge has been more difficult.<br /><br />Why do I think the paths for both roles are similar? Because once-upon-a-time many software developers would have said that agile was asking them to do a bad job. After all, how could you do a good job with no upfront design, no long architecture phase, no detailed requirements? But what developers realised (either quickly or slowly, or perhaps not yet) was that agile values didn't mean doing a bad job, they meant doing a good job in a different way. Part of that was learning new skills and new ways to work. The software/programming community was lucky because they had early leadership in these skills and practices.<br /><br />The feedback I've gotten in the past from UX folk was essentially "when we're in an agile project we can't work the way we work now", to which my answer was a resounding YES! You (as a profession) need to find new ways to work that produce good results faster. It's not your fault that those techniques don't exist yet, or that they may be hard to discover, but that doesn't invalidate the search. But I haven't done very well at explaining that.<br /><br />However, practices for UX professionals on agile projects are emerging now, and Jeff Patton has done a good job of <a href="http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html">describing the practices</a> that he sees working in this context. Moving to agile development means developing new approaches for everyone involved, and it's good that this is now a little easier for UX.Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com0tag:blogger.com,1999:blog-1554986873086232138.post-80714904565061198482009-06-20T02:57:00.001-07:002009-06-20T02:57:41.114-07:00How about the small-law firm model?In reponse to my previous <a href="http://iridescenturchin.blogspot.com/2009/06/allocating-rewards-in-co-operative.html">blog post</a> <a href="http://www.blogger.com/profile/08722634205800520084">Robert</a> said...<br /><br /><blockquote><br />'I've always wondered if the classic small-law firm model would work with IT shops. You know - newcomers start as "associates" and get paid a salary (possibly with bonuses), but the ultimate goal is to get recognised as a partner, in which case you shift to profit sharing.<br /><br />The associate-level allows the firm to recruit new talent at a fixed risk; the partner-level allows for the co-operative mode. As long as the ratio of partner-associate is good (the case in small law firms, not large) the competition between associates isn't likely to be unhealthy - particular if the promotion to partner is merit based rather than "we've got 1 slot open this year".'<br /><br /></blockquote><br /><br />It turns out that we have some of these elements at Cogent, but we didn't have that model in mind when we created them.<br /><br />We do have two groups for allocating profit share. One is like "partners" - it's myself, Marty and Simon. 50% of the profit pool goes to the partners and the remaining 50% is split evenly over all the employees. We needed that arrangement to make it sensible for the partners to stop doing personal consulting and switch to a salary-plus-profit-share arrangement, and even then we're only just now at the point where the partners would nominally break even. It's also rather abstract because as long as we're pushing consulting profits into product development there aren't any cash profits to share anyway!<br /><br />So far this is very similar to the small-law firm model. The difference comes when we consider what will happen over time. It seems to me that the small-law firm model is predicated on growth, or at least turn-over - on the expectation that when you get promoted to partner there will be a supply of associates to generate profits. I'm biased against models that encourage growth (though our existing model has that bias at the moment). Over time at Cogent I'm actually expecting to reduce the partners' percentage of the profit share pool - keeping it enough to keep them interested in staying at Cogent, but gradually making more and more of the profits available to the general employees.<br /><br />There are flaws in both approaches, so it will be interesting to see how the profit share approach evolves at Cogent over time.<br />Steve Hayeshttp://www.blogger.com/profile/05804225687542185765noreply@blogger.com1