thekua.com@work

For the first several years at ThoughtWorks I ran an annual personal retrospective looking back at the year gone by. I value celebrating success, making time to reflect and finding ways of continually improving. I ran them for the first few years before collapsing them back into each New Year’s review.

So what has happened six years on?

When I look at first starting at ThoughtWorks, I was just another developer, almost considered a graduate, because I’d only a small amount of real world experience. I worked for ThoughtWorks in Brisbane when we had an office presence, staying there until itchy feet drove me overseas. I could have moved to another Australian capital city, but London ended up much more of a drawcard with so many more opportunities and access to more interesting aspects to life harder to reach in Australia, such as exposure to so many different cultures (music, food, entertainment), personal travel opportunities and the presence of many professional communities.

To this day, I still can’t fathom working with the same company for six years. When I left university, I assumed two years would be the most I would work for in any company. Being lost in one of Oracle’s massive divisions only served to reinforce this view. So what’s changed? Working for a consulting company brings a variety similar to working for many different companies, yet without being tied to any particular one. Each project brings with it plenty of learning opportunities to uncover new contexts, problems and solutions.

Since being based in London, I’ve worked on at least nine projects of great length (a handful of much smaller ones as well). Unlike many of my colleagues, I’ve worked on many projects beyond web technologies (although I’m sure they’re just as fun). Some of these applications integrated with lots of hardware (think RFID readers, barcode printers, scientific equipment), server side REST applications with extremely high performance requirements, lead several development teams, taught fellow colleagues through our lateral training induction programme in India, and coached some very large organisations on appropriately using and understanding agile methods.

In this time, I’ve been fortunate to work with plenty of bright people, both within our own company and at our client, and grown great personal satisfaction by helping others find a passion for learning and taking pride in what they do.

Seeing a variety of situations and working with lots of different people in lots of different roles has lead to significant growth as well. One of the aspects I appreciate the most about ThoughtWorks is the ability to move between roles and develop skills in different areas. Although we’re trying to put a little bit more structure in place, it’s not a place that thinks you have to grow up or get out like many other consultancies.

So the upsides:

Consulting – You develop many experiences and see many environments, giving you better insights into how people behave and how to overcome undesirable behaviour. This first hand experience is invaluable as you apply it to new environments and new clients. Not being independent means I don’t always get choice of what I work on, but I have to be thankful for some of the opportunities over the last six years (partly of what I’ve made it as well).

Growth – Not everyone takes the time to explicitly focus on learning from people around them. This is one of my core principles. Being surrounded by people who think and have great conversations helps me grow. Being put into new situations, slightly beyond my comfort zone increases my confidence and skill set as does dealing with difficult client situations. I can’t thank of many other organisations where I could develop facilitation and coaching skills whilst moving back and forth between hands-on technical work.

Opportunities – I’ve been fortunate to present at a number of conferences over the years. This isn’t an easy path and isn’t one that happens overnight. I’ll be the first to admit, fantastic story telling at the level of Dan North isn’t one of my strong points, but I like to think many people enjoy the experiential workshops I put together. Opportunities are about making the most of what you find yourself in, such as finding yourself, unwillingly, to work in Copenhagen over the summer lead me to finding that lone free booking at Noma, the world’s third best restaurant in the world and enjoying one of the best meals I’ve eaten in my life.

People – ThoughtWorks prides itself about hiring great people. That’s not to say that we always hire perfectly. However I’m glad to be surrounded by other people who take pride in their work, care about learning and passionately applying themselves in whatever they like. I’ve lost count over the years for the number of work colleagues who’ve inspired me to get better at things that I do, and challenged me to better understand the work that I do. I continue to meet more people like this everyday, and am thankful for that dimension.

And the downsides:

Support – Part of not having clearly well defined structures for people as they “advance” make it harder to plan for the right level of support and to time it correctly. I know of some people who moved on by not getting the right support at the right time, and those who failed to get the right sort of support. This isn’t to say that there is no support but it’s a bit random at times. I know that I was particularly let down during my last year although I recognise I have higher tolerances than most.

Travel – I primarily moved across to the UK because of the strong correlation between project work and the office. This has definitely changed over the years. Travel is a necessary part of consulting, yet made harder when traveling greater distances and amplified by the lack of support.

Consulting for clients is different from working in the office – This is definitely one frustrating elements for working for any consulting firm, and I don’t think that ThoughtWorks is any different here, with a different cultural divide between those working in the field and those working in the office. It’s taken me years to see some of the systemic effects, although I’m sure it will be much more before there is something significant I can do about it. Ask me about in person and I’d be happy to run through my current theory.

The key to retrospecting is about learning, so here’s some of the lessons I’ve learned:

Leadership is not about titles – People I talk to see leadership as a role you are explicitly given. I disagree. Leadership implies taking ownership of responsibility and this is true whether or not you are given it or not. It’s not about a role, or a title. It’s about the way you act and the things you say. The leaders I’ve most respected were those that owned the rewards and pitfalls of responsibilities, regardless of it not being an explicit part of their role. The best teams I’ve worked on ensure all responsibilities are taken care of despite the varying titles amongst the people on it.

Everyone is responsible for passing the experiences on – Working for six years for any consultancy is rare, and part of that comes with a certain responsibility of passing on the right culture, and creating the same opportunities for others new to the organisation. Every individual in an organisation should feel the burden of this responsibility. I’m grateful for feedback from co-workers the difference that I make to them everyday. It’s amazingly gratifying to know that I made a positive contribution to people’s growth, even more so when I already hold each one of them in high regard. It’s so gratifying to receive that random text or email from previous co-workers telling me how they’re still doing, or doing things differently as a result of the small investment I made with them.

People move on – People leave companies. That’s a fact of life. The way I look at it, an individual’s needs and wants change more quickly than what an organisation can adopt. I think it’s the organisation’s responsibility to ensure that it does as much as it can to keep people. I think an organisation’s failure is to not to do what it *could* have done to keep them there. This sometimes happens and it’s frustrating. I think we can also get better at keeping in touch with alumni because we definitely aren’t very good with that.

Consulting is a sharp, double edged sword – The change that brings about new experiences and opportunities also often requires travelling or something not quite matching up. Some people in our organisation believe growth will solve these problems, something I also disagree with. I think growth will simply make it much more complex to solve. Having more people on hand simply makes it harder to get the right people to the right place at the right time.

Learning is a lifetime endeavour – I continue to argue how our education systems force us to stop thinking and learning. We focus on teaching (push) over learning (pull) and worse, we focus on absorbing facts instead of thinking. Our environments offer learning opportunities all the time, yet we’re trained to turn a blind eye to them, or to fail to respond to them. Living and breathing agile methods has taught me to learn first, and judge later.

Comments(6)

I’ve never been to a QCon before and being run by the same organisers of JAOO and the folks behind the ever popular InfoQ, I was looking forward to being both an attendant and presenter. Lasting three conference days and two tutorial days, this conference focuses mainly on being talked at – quite a different experience to the Agile 20xx and the XP 20xx conferences I normally run workshops/talks at. Being focused on the cutting edge and practical technologies side, I can really understand this because it’s hard to target people with the right level of experience.

Talking to most of the attendees, it also attracts a noticeably different side with the majority of people already in architect or senior developer roles with a relatively smaller proportion of people in other ancillary roles such as PMs, testers or BAs.

Feedback that works
I like the feedback note for the conference, asking people tweet, email or talk to people at the conference. I think some of the feedback mechanisms even worked as we saw a lack of caffeine/water during the breaks on the first day change for the other remaining days.

The Keynote
The first day’s keynote started with the evangelical Uncle Bob Martin. He’s a great speaker and channels a lot of opinion towards the crowd wandering back and forth on stage. I saw a version of this at the Agile 2009 conference. I’m glad he adjusted it somewhat more appropriately for this conference. He talked about some good principles that should be followed after a few bumpy technical glitches. He is all about the drama (which I guess is part and parcel of a keynote) such as showing us a video that scrolled through a single java class for something like two to three minutes backed up by a song from the movie from 2001 (thanks Ola!) that almost sounded like the flight of the bumblebee. The point of this showmanship was to demonstrate how we can sense bad code visually without even looking at the specifics. He went through a number of his mantras such as “The Boy Scout” rule, leaving things better than how you found them, or that functions should be no more than four or five lines long.

Whilst I don’t think I learned anything new, Uncle Bob Martin was entertaining and had good things to say, despite how preacher-like he comes across.

Track: Architecture’s You’ve Always Wondered About – Session: BWin – P5 a future proof poker platform
The rest of the day was split into six different tracks. I went to the first of these and was truly disappointed. The two presenters came from BWin, apparently one of the largest poker and gaming sites in Europe. They spent half an hour talking about their problems of performance (many of the -iliites) and where the history of their application came from. They even had to include a three minute video from their marketing folks. They finally flashed up a screenshot of their architecture diagram which I think everyone had come to hear about it. Unfortunately they moved onto the next screen very quickly and said that they couldn’t actually talk about their architecture. How disappointing! Indeed this might have been an “Architecture You’ve Always Wondered About”, and after this session was one to still, indeed, wonder about it.

They proceeded to pick a single example about two processes that concurrently wrote and read from the same database table and their architectural change simply transitioning it to a disk persistent queue and the reporting service reading from that queue and writing to its own database. Neither very profound, or a very interesting tidbit that failed to give the audience any more insight into any interesting part of how they architected their system.

I found it interesting they spent a long time (something like 250 man years) rewriting this version of their architecture so I asked the question about how they went about moving from their old to their new platform at which they pretty much described a big bang approach – neither iterative or incremental. Pretty disappointing.

My lesson learned from this: Regardless of how pretty your slides are, make sure your abstract matches what you’re going to actually talk about.

Track: Dev and Ops: A Single Team – Session: Devs and Ops Cooperation when the Worst Happens
My next session was much more fulfilling with Michale Nygard (author of Release It) describing some of the stories that were the basis for the book but wouldn’t have been publishable. Michael is really down to earth and happy to chat about many of the details behind the book. It’s really obvious that he is also a very pragmatic person, understanding that models are just that and recommending people look into the details because there is often something much more complex underneath.

Many of the things that Michael talked about also resonated very strongly with ideas that I’ve seen on applications. Many of them included focusing on ensuring documentation artefacts should be tested by those who will consume them. As he put it, “UML is virtually useless to the deployment and operations team”. Other gems included, “From a high enough view, everything starts to look the same”

His stories also reinforced the importance of having a ubiquitous language will all members of the company in the shared domain. One of his most successful rescue missions dealing with a production problem only worked because the architect (on the dev side) and Michael (on the ops side) understood enough to really communicate the real problems. Michael also kept (understandably) hammering home the point of lack of information on both sides really hurts the problem solving process.

A lot of Michael’s stories also described their successes working around the existing (organisational) systems in order to deal with the problems at hand. To me, this was just another great example of organisations that structure themselves for efficiency over effectiveness.

I like the way that Michael finished off his talk as well, focusing on the fact that you’re not just trying to build software, that you need to care about the organisation (and I would also argue, the systems and procedures in that organisation) that support the software. Design them for effectiveness, not efficiency.

Architectures you’ve always wondered about: Facebook
The next session I attended was by Aditya Agarwal (one of the engineering directors of Facebook). He shared some great insights and lessons learned into what things Facebook did that got them to where they were. Admittedly they had some strange choices like writing something that converted PHP into compiled C++ and using MySQL is a very “reliable bitstore”.

They have a lot of great things to say, like being very proud of the low number of engineers ratio to actual users. Like Alistair, I’m puzzled why they’re secretive of the exact number of their employees.

Aditya has some good things to say and although he means well, I don’t support everything that he says. it’s obvious a lot of what he says is based on a start up culture. Things like, “don’t worry about it until it becomes a problem” encourages the recklessness we see in many software companies. Same thing about the choice of programming language such as “every programming language will have problems at our scale”.

On the plus side, I was pleased to hear them encouraging the innovative engineering culture that I don’t see in many organisations.

Track: Non relational DBs and Web Oriented Data – Session: Social networks and the richness of data: getting it done with
After going through my notes the most interesting tidbit was about using a partitioning mechanism to deal with data updates based on the number of connections. There was plenty of buzzwords (both internal and external) that I think I had a hard time fitting it all together. Some things I’m going to look at include:

• Bit versus bloom filters – Not familiar with this term or how to use it.
• Tools – RESTeasy (I now see it’s a JBoss project). Redis and Voldemort – something they used heavily all over the place.

That’s about all I got out of this session though I’m not sure if it was about the lack of familiarity with the tools, or the excessive use of acronyms and unfamiliar terms or just plain tiredness.

Track: Functional Programming – Session: Demystifying Monads
Josh Graham did a great job stepping into fill in for his ill wife talking through some of the different ideas behind monads. I haven’t done functional programming since university and I’ll be the first to admit Monad’s are still a mystery to me but I came away with some key learnings.

Firstly, to understand monads properly, you really just have to see several examples in action. There’s a high barrier to entry because it means:

1. Learning a new language
2. Learning a new development environment
3. Playing with plenty of examples

When I find some time, I’ll do those. In the meantime, I understand a bit more about the properties of a monad, and that they can be a powerful abstraction for functional languages.

Final keynote – Dan Ingalls: Forty Years of Fun with Computers
For being so late in the day, this was a very entertaining keynote. Just like any modern day small talk person, this entire demonstration took place in the Squeak development environment. Dan demonstrated some interesting and interactive elements.

I had a few key takeaways including:

• We’re really bad at learning the lessons from the past. Partially because we don’t have enough storytellers and that our generation doesn’t listen very well.
• I’m going to read this article at some point.

Comments(2)

This year proved interesting for those in the agile community, or at least for me. The most commercialised agile methodology lost one of its largest figureheads, and a new community of thinkers emerged focused on prioritising a practice often implied or described as optional in other methodologies. What I found fascinating about a new community forming is that in finding its own identity, it naturally results in denouncing ties with existing communities (to a certain degree) and comparisons about whether or not they are “agile”.

This lead me to ask myself, “What is wrong with agile?” To better understand it, I went back to finding out why “agile” first started. From my understanding, a community of thinking practitioners (not just thinkers) coined the phrase “agile” to unite people working in different ways to help identify with each other. The actual methods for working in an “agile” fashion existed well before they coined the term.

I respect and heartily thank this group of thinking practitioners for coining the term “agile”. A simple word acting as an umbrella that encourages people to swap ideas between communities. I recognise this same “vagueness” that draws people together also makes it difficult for newcomers to identify with what it means.

Look at how other communities relentlessly protect their set of practices, branding and declaring you are or are not doing methodology X or approach Y, particularly when reinforced with certification programs. I’ve realised this same protectionist attitude acts as a wall to new ideas spreading between people and organisations that could be beneficial.

I vouch that the term “agile” remains useful. Let us not forget the original intent behind the word. Let us embrace and create opportunities to continue welcoming all thinking practitioners from different backgrounds to connect and swap ideas and experiences to be more effective and successful.

Comments(4)

A work colleague pointed me out to this fascinating article called, “The unspoken truth about managing geeks” that I think anyone working in IT needs to know about.

There are some great bites of information in there that I picked up including:

• Avoid laying blame on stereotypes and look at the system that drives out certain behaviours (such as those factors amplifying stereotypical behaviour)
• Geeks trust people who help get the job done. Geeks find ways to work around people who don’t.
• Unlike in almost every other area, it’s often not how you say something that matters, it’s what you say. Maybe it’s because of logic but geeks detect when things don’t quite add up.

I suggest you read everything in the article. I don’t necessarily think all of it is accurate at all of the same time but it’s well written and gives people insight into why geeks often behave as they do.

Comments(1)

It looks like I have become a published author along with three other ThoughtWorks‘ colleagues (Adrian Wible, Joe Zenevitch, and Anupam Kundu) in the “97 Things Every Software Project Manager Should Know” book.

I contributed two tips, “Documents as a Means, Not an End” and “You Are Not In Control“.

You can buy it the print or ebook version of the book with a 30% discount via the Orielly.com website, using the code ABF09. Congratulations to all the other contributors to the book, including the author who organised the book, Barbee Davis.

Comments(0)

Thoughts about the second day
Ivar Jacobson gave an equally uninspiring keynote, talking about “What they don’t teach you about software at school: Be Smart!” In it, he focuses on the fact that it’s not only enough to try to “Be Agile”, but you need to “Be Smart”. Unfortunately many of the items that he talked about didn’t really seem to be any different from “Being Agile” and that he had obviously targeted the wrong audience.

I’m glad the conference ran with an open space session, this year introduced by Willem Van Den Ende and Lasse Koskela. I suggested a topic titled, “The Kanban, Lean, Agile Divide” and I felt we had the best quality discussions during this open space. I wanted to answer a number of questions including:

• Did people know about the Kanban Community?
• How active were people in that community?
• Did people perceive a divide?
• And if so, why?

Out of around the 12 people participating, probably only two or three hadn’t heard about the community, and only one or two people were active in participating (in the mailing list portions). We had lots of discussion as to what people considered as Kanban as well.

First page of notes from the open space session

We noted down the mailing list, available on Yahoo Groups: Kanban-Dev and several “published” resources including the paper, Kanban Vs Scrum, and the book, Scrumban.

When asked about what Kanban was the participants, here’s what we recorded:

• Elements of one piece flow (particularly limits to WIP or Work In Progress). Translated into practical terms, it meant focusing on one story at a time (as a team or as a pair)
• Kanban was an alternative scheduling technique
• Unprescriptive, or less prescriptive (relying on other practices to help out)
• Constantly evolving
• “Good for maintenance”
• Most people considered Kanban a “Practice more than a methodology”, though there was general agreement that some people are trying to turn it into more than that
• Focused on delivering “Minimal Marketable Features”
• Quote from Tom Poppendieck, “Scheduling and Workflow are orthogonal”. We expanded upon this for a bit and a more concrete example is you can use different scheduling techniques such as Kanban or Timeboxes with the same workflow such as a simple, “To Do, In Progress, Done” workflow.

I recorded that some people were still doing sprint/iteration planning whilst using Kanban though I don’t remember if we got into the details.

I also recorded two concerns, such as knowing, “When do we get stuff done?” and a very “Loose Terminology” leading to lots of confusion, particularly the overloaded associate with Kanban (as a practice) and Kanban (as a methodology).

When asking the question, “Is there a kanban divide?” some answers included, there is maybe a divide in a community sense, and when probing further, when interpreting Kanban as a practice, not a methodology there wasn’t however there was definitely a sense when treating Kanban as a methodology and not as the practice with a feeling that some people in the community wanted to make money.

Last page of notes from the open space session

We asked why the community divide and understandably, there was no real community around to openly discuss Kanban (as a practice) and felt similar to those that had been around during the XP early days. There didn’t seem to be any general list for “agile practices” with extremeprogramming and scrum-dev mailing lists. It’s also not the first time practices have had their own list, like the pairprogramming or the test-driven-development lists. We did note down that there were several potential ones the community could have joined including lean-agile, lean-dev instead of creating their own kanban-dev.

In the afternoon, I went along to the panel on Lean Software Development although I seemed to come away with the same questions and less answers. One of my questions about budgeting was answered by the next morning’s keynote, while another focusing around the lack of discussion around practices seemed to be dismissed by Mary Poppendieck as, “I don’t believe in practices”, maybe best surmised as, “I don’t know” (which I would have also been happy to take).

The evening was an impromptu beach BBQ held by the awesome folks at Agical. Whilst a small company, I’m glad to see them still as passionate and having grown year upon year with more enthusiasm about a huge variety of topics. The BBQ was amazing and I know that everyone had a great time.

More to come…

Comments(0)

General impressions about the conference
I really enjoyed this year’s conference with the combination of a remote island in Italy and the small numbers (100+) giving many great opportunities for chatting with our experienced practitioners, and a handful of academics about lots of different topics. I found it refreshing that there seemed to be significantly more experienced practitioners and thus, I found it extremely nice to be able to chat about similar experiences rather than simply unidirectional advice I find when present with a higher proportion of beginners.

Who wouldn’t want to gather around this place for some great conversations?

The quality of sesions was better than the last two conferences, once again focused less on the introductory nature and more focused on specific aspects. Of course, I had recommendations about how to improve, particularly the organisational aspects, of the conference and I’ve at least had an opportunity to give that feedback having shared a return train with one of the organisers for next year’s conference.

Thoughts about the first day
The first part of this day was a keynote delivered by lean evangelist, Mary Poppendieck. Titled, “The Cultural Assumptions behind Agile Software Development”, Mary proposed that there are several (American-style) cultural assumptions behind many of the agile practices that make it all the more difficult to implement. She referenced heavily the work discussed by Geert Hofsted in his book, Cultural Dimensions.

I didn’t find the keynote particularly inspiring, nor particularly challenging. Country-based cultural dimensions are just one of the factors that permeate the way that people behave. As an agile consultant, you end up fighting corporate culture, and the systems that encourage and maintain that corporate culture and I see country-based cultural dimensions yet another contributing systemic effect. This does not mean that just because a country has a high degree of individualism, working in pairs or working collaboratively in a team will be impossible (perhaps just all the more difficult). As much as I enjoy hearing Mary speak, I also found her presentation a little bit too heavy in the whole powerpoint presentation with far too much text and outdated clipart.

I also ran my workshop in the morning, titled “Climbing the Dreyfus Ladder of Agile Practices” and want to thank all the experienced people that attended as it resulted in some really rich discussions. We managed to discuss seven different agile practices in detail, brainstormed a large set of behaviours for each, classifying them and classifying them into the different levels described the the Dreyfus Model of Skills Acquisition. The results from the workshop can be found here (photos to be updated).

In the afternoon, I helped out Emily Bache’s coding dojo, focused on Test Driven Development. We saw four different pairs tackling four different coding problems using different tools and languages. I learned about the tool JDave (it’s still a little bit too verbose for my liking), and saw different styles in the way that people executed the code kata. For me, I was hoping to demonstrate more on the pair programming side of test driven development as a pair, and I had a lot of fun even though I felt a little bit out of my depth with the tools. Thanks to Danilo for complementing my lack of experience with tools like Cucumber.

More to come…

Comments(0)

One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.

Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence

Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.

Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.

Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”

Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:

1. What behaviour did you see?
2. What impact did it have?
3. What do we want to change?

Testers should use a similar series of questions (in order):

1. What behaviour did you see?
2. What behaviours did you expect to see?
3. What are the consequences of the current system behaviour?
4. Is that desired or undesired?
5. Do we need to change it?

Apply the guideline above and watch the collaboration improve!

Comments(5)

Systems and standards with good intentions are naught without proper execution. Unfortunately this is where most people get let down. People adopting agile fall into the same traps, but at least the Agile Manifesto guides people in terms of values.

Here’s how I’ve seen ISO9001 being communicated at various clients:

• ISO9001 is a quality management system
• A core part of ISO9001 is about control and documenting processes
• ISO9001 is about continuous improvement

Seems harmless right? Unfortunately the way that people interpret this is as the following. ISO9001 is a quality management system. Quality management system = control and documenting processes. Control and documenting processes = continuous improvement.

Unfortunately most people never escape out of the control and documentation requirements, and the fear of failing and audit that leads to a micro-optimisation. This is why the manifesto talks about “uncovering better ways of developing software by doing it and helping others do it” and prioritising “individuals and interactions over processes and tools“.

Comments(4)

It’s about time I probably asked this question about the new Manifesto for Software Craftsmanship, but seriously, am I missing something?

Firstly, the whole idea about craftsmanship applied to software isn’t too much of a new idea. I remember reading Software Craftsmanship: The New Imperative when it first came out, and how the Pragmatic’s also talked about this concept.

I’m probably biased a little bit because I probably believed in what craftsmanship stood for before being fully immersed in agile for the last five(?) years. A part of me understands why this is important for agilistas. After all, I hear of stories all of the time where in many organisations that focus solely on Scrum without adopting any developer discipline still have a “crappy codebase”.

Yet I worry that it focuses on the wrong problem. I worry that it may be addressing a symptom, not a cause. I worry that it will further split our industry into two camps, those who craft (or should craft) software, and everyone else.

The real question I ask myself when going into new organisations and with new teams is, “Do people care about the quality in their work?” This question applies to all parts of an organisation, all parts of a team, not just developers.

So I’m jetlagged, tired and honestly just ranting a little bit, but I still ask the question, “Am I missing something?”.

Comments(1)