Video - The Three Real Problems in Software Development
I recently debuted a new talk entitled "The Three Real Problems in Software Development" at the Øredev conference in Malmö, Sweden. It's a fantastic conference which you should definitely try and attend (or even speak at) if you get the chance!
You can watch the video here, and be sure to check out the many other great talks which can all be found on the Øredev Vimeo page. You can find out more about this amazing conference at oredev.org.
When Product Focused Development Doesn't Work
Contemporary agile software development processes suggest that in order to deliver great, reliable software we should focus on making the next smallest possible change that brings the most value. Usually this works great, fantastically even, and if you're not already doing it you should definitely read more about it.
I say usually though because like most things, it doesn't work 100% of the time (always read the packet carefully folks). What they don't talk about, is what happens if the smallest change you can make is going to take a dev-pair month? What if the next 3 or 4 'highest priority' changes - as decided by the team as a whole - bring no direct value? This may sound absurd (how can they be prioritised if they bring no value?) but it does happen, especially when stories depend on technical improvements.
If you find yourself in this situation though, most likely there has been a failure somewhere along the way and your approach may no longer be working. We have plenty of strategies and blog posts about moving towards a product focused style of delivery, but what do we do when we feel like we need to move away from this mode of working?
The New Normal
Like many people in my generation, I studied the waterfall model of software development at both school and university level. Knowing what we do now, I often wonder if anyone thought to question it at the time. It was presented so matter of factly; it seemed perfectly normal and I accepted it as such. Many things were this way back then in fact, not just in academia. In the enterprise, waterfall was normal. Writing code without tests was normal too. Sure there was some discussion around techniques but the vast majority of companies simply ploughed on oblivious.
It's impossible to say whether companies struggle more with agile today than they did with waterfall back then, although sometimes it sure seems like it. We have to take a step back and think about the comparison we are making here though. Even though we consider it the successor, agile is still not 'normal' in our industry. Maybe that's for the best but that's not what this article is about. What I'd like to know is, how long does a technology or process take to become mainstream, to a point where we hardly even notice it's there?
Does your team need a Tech Lead?
Tech Leads come by many names and in many forms. You may know them as the Team Lead, Lead Developer, or as a responsibility connected to another title such as Technical Architect. Typically they are responsible for the code that your team writes, ensuring it is clean, well written and maintainable for the future. They may do this through mentoring, pair programming, code reviews, katas & dojos among other things.
This varying nature of the role and title of Tech Lead often creates issues however. There is a problem with job titles in general in our industry - often being awarded as a means of recognition with no meaningful change in role - but the Tech Lead seems to embody this more than other roles. I once encountered an individual with the job title of Team Lead who did nothing of the sort but rather spent their time looking after the holiday rota.
The Gamification of Washing Up
My wife and I seem to be locked in an endless struggle with the dirty dishes. We try to split chores equally (although the more grubby tasks always seem to fall to me) so tend to alternate washing up responsibilities from one day to the next. No we don't have a dishwasher, so this leads to inevitable to discussions of the ilk "Who's turn to do the washing up is it?" and comments such as "I thought it was your day :("
There are various things that complicate this - sometimes we skip days because we're lazy, sometimes we're not there, sometimes we trade turns for favours and so on. The thing that really annoys me above all else though is a very devious activity whereby you take your turn early, for example by doing the washing up at lunchtime while the other is out at work, (sometimes unfairly) reducing the workload on their part.
As the opposite pair in this arrangement this can be galling, especially as our pregnancy progresses and leaving dishes to sit overnight can be met by apoplectic rage. You get home to find that - surprise! - your turn has come around sooner than expected and you get the treat of doing the washing up yet again.
Video - Lifestyles of the Rich and Frameworkless
Ever wondered how much time and effort you save by using a Javascript framework? Back in July I gave a talk at NDC Oslo called Lifestyles of the Rich and Frameworkless, in which I demonstrate how easy it is to build three common pieces of functionality from scratch - Templating, Databinding and Routing - and then tie it together in a simple to-do list application.
Each one takes about 15 minutes and about 70-80 lines of code. It's well worth a watch if you're curious about rolling your own javascript, or just want to understand more about the frameworks you use. You can check out the video here, or view the embedded version below. Code samples can also be found on github. Enjoy!
The Dark Matter Developer's Polar Opposite
Most people remember Scott Hanselman's post coining the term 'Dark Matter Developer' way back in 2012. Suddenly I feel very old, but the term has stuck - primarily because of just how much it resonated with people who remembered what it was like to be in that situation, detached from the community existing in their own corporate bubble.
Personally I don't think things are quite as black and white as this. There's no such thing as 'the community', rather there are many communities. What we might think of as mainstream is not mainstream at all, it's just one of a number of developer groups, some larger and some smaller. One can be a member of some communities and detached from many others, it depends on your frame of reference. For the sake of this article I'll stick to the definition of the community that my peers would think of, the so called 1%, the people who speak at and attend conferences, who write and read blogs like this one.
When it comes to classifying developers in terms of their exposure to the community, it's not binary but rather it's a sliding scale - with dark matter developers at one end. But if it's a scale then it must have two sides, and in this post what I'm interested in is - what or who fits in at the far opposite end of the spectrum?
On Abstractions, Repetition and Discovery
Hands up if you've been in this situation; you are building out a handful of new features that happen to share certain facets. To the customer they are distinct deliverables, but to you and your team it's a rinse and repeat type scenario with maybe one or two tweaks in each case.
The first one is straightforward - you add a view, a controller and so on. The second feature is much the same, view... controller... perhaps you spot some code or markup that can be pulled out into a dependency and re-used between the two.
Then we come to the third feature. You sit back and think to yourself - "these are really all variations on the same theme. I could introduce an abstraction to simplify this. Adding the remaining features afterwards will be really quick, and really simple."
Stop right there. Chances are you're about to make a grave error, and I'm going to explain why.
Don't Blame the Tools
I'd like to introduce three very imaginatively named and fictional projects:
Project A - The people have spoken. Fed up with the inefficiencies in their company the developers have risen up and make their needs clear - they want Agile, and they want it now. The company needs developers, so the concession is made.
Project W - Run by an in-house team who've been doing their thing for 15 years. They know what they want, they have a spec and by heck they're going to follow it because they've always done it that way. Slow and steady wins the race.
Project a - Top of the line consultancy firm ThinkShirts has been called in to deliver this key project. To them agile is a set of ideals to strive for but rarely achieved. They are pragmatic and use only the techniques that they find useful.
Three different projects, three different teams, but at the end of six months all three projects have failed. Projects fail all the time, but in this article I'd like to explore the potential causes for failure in these three specific cases.
Video - The Myth of the Qualified Developer
The video for "The Myth of the Qualified Developer" recorded for the London .net metup at Skills Matter is now available online.
About the Author
Pete is a software consultant, speaker & writer living near London, UK. He started off with C# and Javascript, and nowadays likes to code in Scala. He enjoys running training courses and speaking at conferences. Sometimes he works on OSS, and one time he even finished something.
Latest Tweets
Recent Posts
Blog Tags
2015 © All Rights Reserved. Privacy Policy | Terms of Service