First up, is this most excellent post from Joshua Arnold over at Black Swan Farming. Called “Standing Up Doesn’t Scale” it’s a comment on “false friends and local maxima”, that is having standups and kanban boards, without actually knowing why you’re doing it and what problem you’re trying to solve. Too many organisations are like this and it’s frustrating for everyone involved -especially those hired to help with the transition in the first place.
#noEstimates is a torrid love affair of biblical proportions and, by biblical, I mean magic pregnancies! Anyway, I liked this post from Glen B. Alleman over at Herding Cats because he’s, again, poking a stick at fanatic dogmatism. I don’t agree with everything he says, but it’s a good speech from the prosecution. The Problem With #Noestimates
One for the people people here. Hiring is one of the most important things you have to do in a business – no, seriously, it is. Hiring the wrong people (or, the right people for the wrong role) is hugely damaging to your company. This post talks about what it takes to hire hire an engineering manager. From Calille Fournier at Elided Branches, Hiring Engineering Managers: Screening for Potential
More of this “programmers are artists/crafters/code artisans — they should be treated like special snowflakes!” rhetoric — it drives me nuts!
I agree that writing code is an art and a craft. It is not like building a wall or working on a production line — it doesn’t have defined processes and actions like those.
However, posts like this ignore that simple fact that most business are in business to make money, in order to do that, businesses need to have *some* idea of when things will be delivered, or how much of a thing will be delivered by a certain date. This could be to support a marketing initiative, or because they need to order some hardware or other with a lead time that cannot be changed (and, having this hardware in inventory and not in use is waste), or simply because that’s the date that it needs to go to market.
So, let’s take the two metrics suggested as superior to “productivity” (whatever productivity is — is it story points?).
Value: Yes, let’s do the highest value items first. Let’s generate as much value as possible. “Which items are most valuable?” “How they hell should I know, we haven’t made or deployed it yet — we’ve done some focus groups and monitored our competitors, but we don’t really have a clear idea of which is the most valuable, so we’re guessing”. You’re just passing the whole “productivity” issue up the line, let someone else decide what we should build based on their own set of made up metrics and measurements.
Cycle time: Yes, this would be absolutely wonderful if we could measure everything by cycle time, but when you’re elbows deep in making a product, do you stop to care about how “big” (or whatever sized you use for a story) is to be able to compare it to other size stories to understand cycle time? (The premise being that, to gauge cycle time accurately, your work-items should be similarly sized) then you’re just back to estimating productivity again, surely? “Well, this is a small/8/dog sized story and we have usually done those end-to-end in a week/month/quarter, so expect this delivered around …”
There is no good answer to any of this. Forever more, we’re going to be working with unknown unknowns, sketchy, made up requirements and changing technical and business landscapes. I agree that wasting too much effort on measuring productivity is waste, but claiming you should measure in value or cycle time because it’s a better measure is misleading.
If I told you that a wall I have built previously was 14 bananas high and 82 bananas wide, you could probably build me a similar size wall. Whether it’s bananas, penguins, story points or inches, we’re only every using them relatively to gauge what might be based on what was — which is all estimating really is, no matter what method you use.
Possibly the most frustrating, emotionally bankrupt and redundant four words you’ll ever hear in the workplace.
I recently had the displeasure of hearing these words. Not, thankfully, said to me however. What made the whole situation worse was the person who uttered this charming sentence had allowed the policy to be bent only the day before.
“Policy” as described by the OED is:
a course or principle of action adopted or proposed by an organization or individual
“Policy” as described by most companies is:
a rule which we can use to bash you over the head in order that you do our bidding.
Policies are usually created as a sledge-hammer answer to a walnut sized problem. In the past, someone (or many someones) have done something which was bad for the company (or, another company) and this has resulted in their being a policy.
As a general rule, humans work for, or with you. As we all know, each human is a unique a beautiful snow flake. Trying to apply a “policy” to govern the actions of behaviours of your workforce as a whole is pointless and demeaning. Take the time to understand the people who work with you instead of putting your fingers in your ears and going “lalalalcompanypolicylalala”.
The only policy you should have is one of common sense and decency. Treat your staff like the people that they are, not the resources that Taylorism would have them be.
“OH HAI, THE 1950s CALLED, THEY WANT THEIR IDEAS ABOUT HOW TO WORK BACK”
(Also, beginning the statement with “sorry” is also disingenuous – if you really were sorry, you wouldn’t have to say it in the first place…)
I recently watched Liz Keoghs “Let’s be honest…” YouTube that she did at the goto; conference. It was a fun and engaging talk, but I was frustrated and, frankly, surprised that there are companies or individuals that need to be told don’t lie. She used examples from previous positions to illustrate her many points, but there were two that stuck out for me (well, most of the points were salient, but these were the two that had the most impact on me).
The first was her statement that we’re no longer finding better ways to build software, we already know how to build software, we’re finding better ways to discover. Liz had the sentence from the agile manifesto on screen when she said this. Now, while I’m still not entirely convinced that a nearly 12 year old document is as valid now as it was when it was written, I believe that, if any of it is true, then that be is – we’re still finding ways to build better software. The constant evolution of our industry is testament to that. Don’t get me wrong, we’re much better at it now than we’ve ever been, but it would be arrogant to announce that we’ve reached the pinnacle of software development. Even if you’re a super-duper, high perfoming, cross-functional team, if you stop trying to improve, you’ll rot from the inside out.
This doesn’t mean that the rest of Liz’s statement is wrong, we’re also finding better ways to discover what our software should do, the fact that BDD is now more popular than ever means we’re trying harder to find out more about our products, not just how we build them.
The other thing Liz said in her talk was about user stories and how, we’re lying if they’re not actual stories for the user. Gojko said the same thing in his angry Monday blog post and it got me to thinking. Gojkos was a better example in that “As a user, I want to register, so I can use the site.” is probably a lie – no user ever wants to registers, it’s a necessary evil we perpetrate over and over again in order to provide some persistence for the users’ experience – however, we have the story because we think we should. It might be better phrased as “As marketing, I want the user to register, so I can send them email” or similar (Gokjo has other examples).
But, for me this misses the point. The stories are a catalyst for conversation, what they actually say should really be irrelevant. They could say “Login” and just a a placeholder. This will force the people involved to talk about what that means and how they should build it. It’s this conversation that needs the to be focussed and honest, not the story card. It also needs people to think differently about how they go about the discovery process and this, for me at least, is key to what both Liz and Gojko are saying.
I believe that, for the most part, we lie without knowing we’re lying (is that even lying?). We make verbal assertions about thing X to move us passed that to get to thing Y. The danger then, is that you don’t revisit thing X to work out whether or not your assumption was correct. Do the quickest, most expeditious thing to move you from nothing to something in order to find out if you were right, if you spend too long worrying about whether your story card says the right thing you’re going to miss out. After all, it’s all about the users, get it in front of them and let them tell if you’re lying.
Finally, I believe in starting from a position of trust, this means that I cannot entertain the idea that people are lying until it’s proven they are. The people around me (and, hopefully, you) don’t lie. They’re professionals and adults and shouldn’t lie. If we ever find ourselves in a position where we have to point this fact out at a conference, we’ve got much bigger, darker problems than what we write on story cards.
Technical debt can come in many forms, but is your legacy codebase really technical debt? If you make decisions based on the knowledge you have at the time, can the problems these decisions cause later (either weeks, months or years later) be called technical debt? I don’t believe so. If we’re going to use the analogy of taking on a financial burden, then you wouldn’t be able to take on a financial debt without knowing about it and, if you somehow did manage to do that – would you even be responsible for the debt (if we think about how those who took on a credit card with PPI are now claiming all that money back)?
There is plenty of discussion about what technical debt it on the internet. For example,Wikipedia sez:
Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.
In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
My question is then, if you write code, or architect an app to the best of your ability, with the best code you can – no cutting corners, or missing tests – is it technical debt when you come back to the code months (or years) later, and it requires huge refactoring because it’s out of date?
I would suggest that no, it isn’t.
If it’s part of your system that hasn’t required work since you wrote it, then it’s simply legacy code. Technical debt is smelly code that you create deliberately. That is, you need to cut corners, or hack stuff, to get your code out of the door quickly. If you know you’re not writing the best code or architecting your application correctly, but you do it anyway, that is technical debt.
The thing about technical debt, like real debt, is that over time, intrest accrues. Let’s say that on day one, you deliberately create some smelly code in order to get something deployed quickly. You decide to fix it the following week. A week later, it takes you two days to write the code correctly.
Let’s say, however, that you couldn’t fix it a week later – something more important came up – instead, you could only fix it a month later. Now, because the codebase has moved on – other devs have committed code, you’ve committed code etc etc – what would have taken you two days to fix a week after you wrote it, might now take you five days to fix (assuming that for every week, the code gets complex enough to add another day to fix it). This means, your interest on this technical debt is roughly one day a week. So, if you leave technical debt for months, it’ll take much, much longer to fix and, depending on your position, every new dev you add to your team will compound that interest, until it spirals out of control and you end up declaring bankruptcy and re-writing the codebase from scratch.
Sound familiar? Might as well do it properly the first time round…
Building high-performing teams requires a foundation of core values in order to channel the traits and skills needed to be successful. Sounds like marketing blurb right?
Let’s break it down into manageable chunks.
What is a high performing team? The answer, I suspect, will differ depending on who you ask, but when asked of a team of software engineers or developers, they’ll tell you it’s a team that can do anything, do it quickly and do it right, while maintaining rhythm and a steady growth of both the team and it’s individuals. The question is, how do you build this team? Firstly, you need the right people. Hand-pick your teams, or don’t – it’s up to you. Great success can be head with constructing teams of star players as well as having teams of volunteers. After that, it’s about coaching the team to performance and that needs to start with core values.
These values should contain the following at least; respect, trust, openness, focus and commitment. If you get your team to help craft these values, they may come up with a few more. Make sure the team understands, or comes to an agreement on what each of these mean (focus is a good one, what does that mean? Can you have focus if you’re having fun?).
With the foundation in place, the skills and traits build on top of that. Depending on your team these will differ also, but some traits will always be there; the team will be able to self-organize, they’ll be totally committed, an unshakable belief in themselves and what they can do, they’ll be responsible and own their own problems, they’ll be motivated and engaged.
With the foundations in place and the traits emerging, a high performing team will emerge, they’ll get stuff done, the right stuff and they’ll do it with pride, skill and a devotion to quality.
My thoughts are with the people of Japan who, right now, are under an onslaught of enormous proportions from mother nature. First an earthquake to fuck shit up, then, if that’s not enough, a tsunami to mop up anyone lucky enough to have survived the initial catastrophe.
Nice one mother nature, sometimes you can be a bitch.
I saw a tweet today that said:
Hellicopter flying over me on Ocean Blvd urging people to move away from the water but herds of people still coming hoping to see a #tsunami 11/03/2011 16:52
And it reminded me of the sci-fi book, The Moon is a Harsh Mistress. Where a penal colony on the moon starts a revolution and demands independence from earth. The only weapon they have is a giant catapult used for firing barges of grain at the earth. They repurpose it to throw rocks. These impacts are worked out by a computer, so they know where they’re going to hit. They inform the people of earth when and where these rocks will hit (mostly government buildings and military installations) instead of people moving AWAY from the impact zones, they move toward them instead, to get a better view of the show … and end up dead.
Don’t be stupid people, stay away from the danger.
I used to have an account with Servelocity. They were fairly cheap, but their implementation of Plesk was shockingly buggy and their customer service was non-existent, even if you used the premium support line. I did kind of feel sorry for the staff working there as they even seemed to give up using the forum after a while as they would just get trolled.
Today, I received this email and it’s testament to everything that is wrong with a webhost that has this on their support page: As the majority of our customer base are highly technically able and in order to provide the most competitive product possible our private servers do not come with support as standard.
We advise that Servelocity Ltd. will not be able to offer services to you after the end of March 2011.
Why Thimbl should win the Transmediale/Mozilla Foundation Open Web Award
The Telekommunisten Collective thinks that people should finger each other as often as possible. Maybe even several times a day, hell, why not once an hour? As often as you like!
People thrive on interaction with other people. Mutual stimulation is a deeply felt human need, a key characteristic of what makes us human. Imagine that instead of reading your status updates on Twitter or Facebook, your friends would just finger you instead.
The Finger protocol was originally developed in the 1970s as a way to publish user and status information, such as who you are, what you’re working on, and what you’re doing now. This is how the relatively few folks with access to networks posted pithy personal bios. From when colourful polyester pants were still groovy until the 90s people used to Finger each other all the time! Finger evolved into a completely decentralized system, where any user could finger any other user as long as they were both on the Internet. There were no big companies in the middle to control these users, or monitor them, or try to turn their personal data into money. Fingering was a personal matter between users, direct and unmediated, and nobody really knew exactly who was fingering who. Promiscuous, right?
Sadly, these heady days of open relationships slowly came to an end. Finger software was developed before the Internet had many users, and before development was driven by commercial interests. The idea was bold, but the software was primitive. Capitalists and their desire for profit have no interest in such freedom and promiscuity and chose to instead fund centrally controlled systems, in which they are intermediaries. Investors wanted control, so that they can commodify and monetize these relationships. Instead of users fingering each other with reckless abandon, people are now stuck with centralized, privately owned services like Facebook; chaperoning their relationships, imposing user policies on them, and monitoring and monetizing their conversation.
Back in June 2010, Telekommunisten had had enough! “People must be freed from these puritanical, controlling, consumerist, profit-seeking cults”, they thought. If witchcraft, wet shaving, rocker hair and skinny jeans could make comebacks, why not Finger? The Thimbl project was born, and immediately started working on giving the project an online identity and releasing tools to create a microblogging platform built on Finger, that groovy 70s protocol.
In October, Telekommunisten received the news that Thimbl was one of three projects nominated for Transmediale/Mozilla Foundation Open Web Award and almost immediately, Thimbl broke on Hacker News and the project started to attract significant interest. Thimbl started popping up all over the place: P2Pfoundation, ecopolis, alt1040, O’Reilly Radar, OneThingWell, Ecrans, reboot.fm… Evan Prodromou from competing service identi.ca even took a playful swipe at us!
Finger was becoming cool again. The masses were longing to finger each other!
In a few short months, without much in the way of a marketing strategy and with a budget that could be stored in a matchbox, Thimbl has managed to gather over 250 followers on Twitter – the very service it someday hopes to compete with – and has been the subject of hundreds and hundreds of tweets. Thimbl even has a small following on identi.ca, which is closer to the heart of Thimbl than the service with birds and whales. The thimbl.net website has over 300 ‘Likes’ with its Facebook button and the Telekommunisten Facebook fan page is abuzz with talk of Thimbl. The project has even gathered over 100 votes on the Drumbeat platform. Not bad for a project that was completely unknown to all but a handful of people when the award nominations where announced!
Still, the problem remains: Capital will not fund free platforms like Thimbl. Even with the buzz Thimbl has, building a community big enough to actually create a viable platform without financing is a major challenge.
Wouldn’t it be great if Thimbl could actually win the Open Web award? The endorsement of Transmediale and the Mozilla Foundation would be a tremendous boost for the project, perhaps enough to give the community the needed escape velocity to break free from centralized social media like Twitter and Facebook and make Finger the once and future king of personal status updates! Transmediale and The Mozilla Foundation had a great idea: instead of having a jury decide the winner of the award, present three projects to a community engaged with the open web and its technical, political and artistic dimensions. Mozilla had recently launched the Drumbeat project, just for this purpose, as a hub for projects that embrace the open web to get support and find contributors. So it made perfect sense for Drumbeat to host the voting for the award.
Drumbeat is a fantastic initiative from Mozilla and has a really promising future. However, Drumbeat is a relatively new platform. As a result none of the projects received much attention from existing Drumbeat users or from the Transmediale community jumping on to Drumbeat to participate. The idea that an impartial community would consider the three projects and select a winner didn’t quite work out. Instead, it has become a competition to rally the existing supporters of the three projects to sign up to Drumbeat and vote for them specifically, without genuinely considering voting for the others. This means that, honestly, the vote count is about as impartially meaningful as a Florida election run by Diebold.
Thimbl is up against two cool projects as candidates for the Open Web Award; Booki, the book publishing platform behind FLOSSManuals and many great book writing sprints, and Graffiti Markup Language, a project to enable analysis and archiving of graffiti writing which has the support of many awesome, large and active communities like F.A.T. Lab and eyebeam. If the open web award is really meant to give well-earned support to existing, successful projects like Booki and GML, then we will celebrate their success with them at the award ceremony in a few days. We readily concede that Thimbl has not yet achieved anywhere near what these projects have and that our community is much, much smaller and far less known.
Unless we succeed in our desperate bid to convince Lady Gaga to dump Polaroid and instead dedicate her star power to the cause of ushering in a new golden age of rampant fingering, we are very unlikely to win based on Drumbeat vote count. But if Open Web Award aspires to “clearly demonstrate the unbound potential of the open web in ways that can spark new thinking and practices,” as stated, then, damn it, Thimbl is the most about the open web!
We live and breathe the open web, directly addressing the technical and social issues facing the open web in every aspect of the project, in the code, and in our manifestos. We talk to anyone who will listen about how the open web is not just critical to the future of the Internet, but to society itself. And people are beginning to take notice.
Selecting Thimbl for the Open Web Award at Transmediale would be one heck of a powerful spark. Igniting the new thinking and practice that led to the idea of Thimbl with a clear and bold statement of support for an open web that is truly open! The multitudes are trapped and frustrated, clinging to their social interactions within sterile, commercial platforms, longing for wanton, unbridled realms of contact.
Join us in inscribing upon on our banners the revolutionary slogan, “Don’t be a Twit, it feels good to be fingered!”