Stephen Colebourne

I've been turning to the Cynefin framework - https://lnkd.in/eT66i4uR - more and more recently. Partly, to debunk the myth that an agile development process is always better (or always worse) than anything waterfall-y. But often to help explain why we can't tell you precisely what we will deliver on day 123 of the project. In a complex environment, working out precisely what to do *is* the bulk of the project. And this by Audree Fletcher is bang on. If your problems are complex, and if they include people, they almost certainly are, then please don't demand predicability in their solutions. https://lnkd.in/eUk_-s8h

5

I'm observing a team writing code as an ensemble without TDD. I am selfishly delighted in the confirmation of how valuable TDD is to me as I use it. The team is implementing a new function that's doing list of list manipulation and returning something. They are all over the place with naming things, creating objects, streaming, mapping, flattening maps, return object, variables, naming...so many squirrels. Too many squirrels to even really focus on "what's the simplest first thing we could do?" TDD is so much more than writing a test first. It's a framework that helps me focus, prioritize, structure, and order my thoughts. Test Driven Development is an immensely helpful design and focus tool. I should also note, that I am beginning of working with this team and meeting them where they are. #codelife #devlife #TDD #testdrivendevelopment #unittesting #designthinking #problemsolving #structuredthinking #focus #mindset #toomanysquirrels #codingchaos

282

62 Comments

I think I may be a little late to the party here but, blimey Charlie testcontainers.com is super useful for your integration tests. 1) I can see why Docker snapped up the developers, AtomicJar 2) testcontainers.com may make building integration tests just a little too easy

6

I don't often post things like this but I'm seeing a lot of misinformation around TDD and it not working or is a failure. I've been responsible for implementing or pushing TDD for over 15 years now and have gone through various different frameworks, and methods. When I joined SRL there was a growing bug problem, and zero worth unit, integration, or UI tests. Over the last three years Martin Thorne, Steve Pugh, Olufemi Adesina, Kathryn Beggs, and latest recruit Maude Williamson have worked diligently to create Unit, Integration and Cypress UI frameworks in place. The coverage for each is on average over 80% and continues to improve. It is the responsibility of developers to test their own code and is often the first line of defence against poor requirements. We're now averaging +1 bug/month reported from clients, and usually these are P3, P4s, or disguised scope creep. Simply put TDD DOES work - but as with any skill if you've not got genuinely experienced people then it's going to be a mess. *Ahem* Agile my eyes are on you.

18

1 Comment

Interesting paper about property based testing in real usage. Looks like as with any written tests it can help devs have clarity on their solution specs and helps document code. Harder to implement but more valuable when in place. https://lnkd.in/g_UEJvXW

5

Fascinating conversation on the Continuous Delivery channel about how to persuade other developers to try techniques like TDD and CI. After a decade of trying from 1999-2009, I came to the realisation that - frankly - you don't. Dave Farley makes a good point, which I try to impress on teams asking this question; talk to them about problems that matter *to them*. It's very helpful to understand the symptoms of poor code craft, like slow release cycles, frequent in-production failures and failed roll-outs (and out-of-hours firefighting), angry end users (work as a developer on a trading floor if you want to see genuine rage), regular "crunches" with long hours to get software ready for release, and of course, the accompanying burnout. And if they're on the business side of things, long lead times is usually a big issue. When s/w is a core part of a much wider strategy, telling the business they may have to wait months for a new feature or a change - or that it might never happen at all - is bad news, which is probably why most teams won't actually *tell* them. Finding out's the fun part... When we're selling a solution, it's usually best to start with the problem :-) My solution sales training taught me to stick to the problem for as long as possible. We need them to relive the pain, and if that pain isn't big enough to warrant changing their approach (which can bring other kinds of pain), then it probably won't happen. People tend not to change unless they really have to. And if they've not experienced the pain yet, then selling them a cure is very difficult. Sometimes you just have to wait for them to get their fingers burned before you suggest investing in some oven gloves. On the question of data: if you're trying to understand where your problems are, and what impact changes to your process might be having, it's very useful (if it's *good* data, and that's a whole can of worms). But when it comes to changing minds, data's the proverbial chocolate teapot. People - even highly educated people - aren't rational at the best of times. We operate on feelings and instincts and unspoken incentives and agendas. It's these that can open the door. Data's for the already-persuaded. And, often, the real answer is "Just do it". Lead by example. In larger organisations, I was usually in the *only* team doing TDD, CI etc at the beginning. Once other teams, and managers, saw us delivering reliably week after week after week, mindsets sometimes shifted. Sometimes.

44

Why do I favour practices like developer testing, TDD, refactoring and continuous integration? It's to enable rapid & sustained evolution of production-ready software. The odds of delivering the right thing in a single pass are so remote that many iterations are likely required. And even when we hit the bullseye, it's almost always a moving target. Not least because putting software into an environment has a tendency to change that environment and the problems we need to solve.

43

Trying to hire a junior to mid-level engineer in Scotland with great benefits and remote working is hard... https://lnkd.in/eQNHVqGR Not because the role isn't attractive (you'd be working on exciting large-scale system infrastructure challenges writing code with Golang - 1,000's of Kubernetes clusters, 10,000s of cloud VMs) or because the team are all crazy (they're thought leaders in their field including multiple upstream Kubernetes contributors from 3 continents!)... you got me... maybe there's a little crazy - but only the good kind! No... my challenge is whether this AI-generated image to go with my LinkedIn post makes any sense! I never have much luck with images containing generated text. Even using prompts like "spell check any text" or as is the case with this one "do not include any text" doesn't seem to work. Not to mention, I know what a Scottish Terrier is... but that "thing" in the bottom right looks more like an angry, tartan-wearing Capybara. Comment below for your biggest concerns with this image... or if you're a junior/mid-level, talented software engineer based in Scotland - maybe just skip over the image and apply online - https://lnkd.in/eQNHVqGR

61

12 Comments

Here's a concise representation of your ML platform, courtesy of Laszlo Sragner.

1

Interesting discussion with Dave Farley and Emily Bache. There are a lot of things that I agree with in it, however the one main sticking point that I have is that a true "engineer" in the more common incarnations, Mechanical, Civil, etc, require registration and licensing from a local state/district and/or governing body. I'd LOVE for programming to have such a system, but we currently don't. That's one reason why I settle with code craft and call myself a crafter. I agree it's not a perfect term, but to me its better than giving the false impression that there's a standard of skillset or understanding like other engineering disciplines. What do you think? https://lnkd.in/gXqmkden

15

31 Comments

Great post from Holly Donohue - the round table discussion on measuring developer productivity at #CTOCraftCon was really interesting. If we're focusing on team impact vs individual output, what should we be measuring? Some ideas I'm exploring at Treecard: 🐛 Number & type of bugs produced per cycle Why? If we're building impactful features with minimal defects we'll be the most efficient at reaching PMF. How? We categorise the bugs into things like missed spec, insufficient testing, regression etc. We graph those per sprint, if we invest effort in focusing on a particular type of 'bug' - we expect to see that type go down over time. 💯 Sprint completion rates Why? If we're committing to delivering work and not meeting those targets, either we're loosing focus mid-sprint and working on the wrong things or the target was bad to start with. We need to work on the right things consistently to get to PMF. How? We use Linear and they provide some basic analytics to help with this - although we export raw issue data into redshift for deeper analysis. Recently we rejigged our setup so each team maps to a team in Linear. Previously we had one 'Engineering' team which made sprint completion, burn down etc hard to measure. 📅 Meeting target release cadence Why? We need to move quickly to reach PMF, we should be shipping value regularly. If we're not shipping we're not getting closer to PMF. How? We've recently introduced a fixed schedule for releases rather than just shipping when it's ready. This generally meant we had very large releases as there was no push to get stuff out the door. We can track these against sprints to see how we're doing at shipping frequently. Curious what other teams (especially early stage startups/pre PMF) are using to measure & improve on team productivity?

6

An important read, and a topic near and dear to me.

3

1 Comment

Another brilliant post by Matteo Casu (Semantic Partners) and the folks from Ontotext! Interested in Semantics and LLMs? Talk to us. We'll help you in driving a solution forward. #rag #llms #genai #knowledgegraphs #ontologies #semantics

2

Day 2 at #LeadDevLondon LeadDev What a great conference! I'm exhausted. More fantastic talks today and I got to meet loads more exciting people (hi to you all!). Again too many talks to comment on individually, so again I'm going to pick out themes. 1. How do you make decisions? This seems to have been a running theme across all three days, but there were great talks about it on day 2. The first thing is you are going to need to notice that you are making a decision at all and take a moment to step back. Things to weight up: - Do you have existing biases? - Have you stepped back far enough to consider all the options? Throwing in some wild options is a good way to open it up. - What are the upsides? - What are the risks? - Who needs to buy into the decision? (Not just your line, but also other teams who's support you are going to need, or customers/teams that you want to use the output). - Do you have the skills? Or are they skills that your team would like to gain? - What are the maintenance costs? If this is a migration are you really going to be able to get rid of the legacy system? How quickly? - What are the repercussions for other teams/areas? - How are you going to get feedback as the project progresses? Metrics? People? - Above all, is this going to be fun? As you go through all those questions and indeed the project be curious, humble and empathetic. 2. Humans > machines, metrics, process.......... If you are putting people first you probably aren't going to go too far wrong. That isn't to say there isn't a place for all those other things, but they are there to assist people, not the other way around. If people are giving you a clear signal, you better listen to it. 3. Finally some practical advice from the bug all stars talk: - Be explicit in your APIs, make it super clear exactly what parameters/outputs are. - Get help whatever help you can to validate your code, whether that is from people, or from tools. - Don't try to solve difficult problems that have already been solved, use existing hardened libraries. Thanks to all the speakers/organisers, you were amazing. Thanks as well to my LeadDev buddies: Jen Kitson, Yanqing Cheng, Alice Twist, Daniel Phillips and Macauley Davy, sorry I didn't catch you all for the photo before you left. Finger's crossed I'll be back next year!

63

2 Comments

Still got it. ("it" being the ability to do medium-hard leetcode exercises in a generous amount of time. I got absolutely flattened by one of these a few months ago which threw some much harder problems at me - there is a threshold of difficulty above which I really do need to go away and think about it a bit without the distraction of a ticking clock. When conducting live code test interviews I've often seen people fall on the wrong side of that threshold, sometimes for quite "easy" problems, and it's hard to say whether this is truly indicative of a limit to *ability* as such. It seems to me that there are at least three factors in play: 1. General familiarity with the space of "data structures and algorithms", and the ability to find a good answer using the tools and techniques you have at hand. This is what we generally tell ourselves we're testing for. 2. The ability to pattern-match that knowledge to arbitrary, and often quite whimsically expressed, challenges quickly enough to head off expeditiously down the right path to a solution, by using "fast" (heuristic) rather than "slow" (reasoning) thinking. This can be something a bit more like "muscle memory": people who do a lot of competitive coding challenges will tend to be sharper at it. To some degree this is indicative of accumulated experience and the intensity of someone's recent engagement with hands-on coding, in which we are also interested as interviewers. I've usually been impressed when a candidate's taken one look at the challenge, gone "oh yes, it's one of these", and rattled out a solution almost mechanically. On the other hand, it's not telling me much about how they reason their way through problems that don't yield to their heuristics. 3. The ability to use either kind of thinking under time and social pressure, which varies somewhat. Some people do freeze, and while I've always tried to help them out when interviewing it's not always possible for them to find their way back to the required presence-of-mind. Are the kind of time and social pressure you're artificially creating in your interview typical of your real working environment? Then I guess it's appropriate to penalise candidates who won't thrive in that environment. But it may not be the sort of place where real "slow" thinking gets done very often, and that might be a problem for both you and a thoughtful interviewee. There are lots of candidates, and we have to screen them somehow: the all-day on-site interview process I once went through at TIM, An Acuris Company might be unfeasible for most organisations now. But it was also a good experience and gave a fair picture of my strengths and weaknesses, and from what I saw while working there it brought in good people.)

19

4 Comments

The modular software - micro services - exhibits two critical architectural properties - testability and deployability in isolation. Contract tests help teams make progress without depending on other teams. This should be a good read when it comes out #microservices #softwareengineering #modularity #contracttesting

1

Learning about, becoming aware of, TDD is easy (30 seconds or less). Building proficiency in it is/can be complicated. Gaining fluency, well that takes time and actually using it. One question that I've been thinking about lately, with TDD, is inspired by a talk I watched by Llewellyn Falco where he mentioned that TDD is challenging to learning because it incorporates about 18 different skills . Trying to get more proficient at 18 different skills at one time is most certainly a challenge. I've been doing different breakdowns of the different skills that TDD incorporates to better develop practices that target those individual skills hoping that will boost TDD proficiency. What individual skills do you think make up TDD? I bring up three different sub-topics that I can talk about more if folks want (or I can post about them separately too). 1. Awareness -> Proficiency -> Mastery/Fluency and skill acquisition 2. Benefits of fluency/mastery over just being proficient 3. Optimizing becoming more proficient with a skill

24

8 Comments

TDD is expensive Like many other niche technologies Delivery of software is not only a technical problem It’s logistical and people problem as well It can be using Kotlin in Java company It can be adding a better database engine It can be applying Event sourcing to all systems You can say all of those are great But there are a couple of non-technical problems 🧠 Knowledge The whole team must know the new solution They need space to learn and practice You may get training from an expert Both cost money and time 🚦 Risk You face the bus factor What if the devs will leave? (they will) How will you maintain the niche solution? How much will it cost to hire or train a replacement? 👩 Hiring Adding new technologies narrows the pool of hires The more niche you go the harder is to find a good fit The longer hiring process will strain delivery You'll have to balance with higher salaries ☯️ Alignment What about your current team? 80% of them like tests but aren’t fans of TDD What will you do? Force them to learn or let them go? The culture will take a hit and retention will sink What can you do instead? Keep it simple Keep it boring Focus on the basics Drive incremental improvement Find alignment before picking new tech Get excited about the features and business If you don’t need to fix niche problems You get more time to deliver value

24

13 Comments

When people ask me if I think AI will make software developers redundant in the next few years I think about the tiny amount of code out there that is easy to understand and change over time. Given how we still struggle to write simple CRUD based applications that are easy to evolve to meet the next challenge and we are teaching AI based on this data set heavily weighted towards mediocrity I don't worry that good developers will have no work.

8

11 Comments