James Forage

Great to see that CDDO / GDS have updated their guidance page on the use of Progressive Enhancement on UK Government services 😍 https://lnkd.in/esuSVb29 Keep fighting the unnecessary bloat that JavaScript has brought to the modern web! ✊ #a11y #accessibility #webperf #progressive #enhancement

95

7 Comments

Interesting investigation of transaction cost of Pull Requests by Dragan Stepanović with Dave Farley Continuous Delivery Ltd Interesting with some data about: * 10 lines of code => 10 issues. * 500+ lines of code => LGTM :-D == Impact of Pull Requests on Work/Wait ratio == Wait time in processes, is the time it takes for work to wait at a station/gate before moving forward. A pull request is such a station. This wait time is what we want to reduce in Lean. And want to reduce in Agile methodology. This translates to ratio for time to make a change and create a pull request vs. wait time to get it approved and merged. As an example. If a change takes half an hour to make, but 2 hours to get approved, that is a ratio of 1/4. This means tasks are waiting by a factor of 4 to progress further. Or, viewed from a different angle, developers potentially getting a WIP factor of 4 to "keep busy". (Note that the best work/wait is ∞ or wait/work ratio is 0 which is more useful) The are many different goals and means that work counter to each other. A complex system of interdependent watt governors. To improve the work/wait ratio, require more frequent interruption of work/flow of team members. To lower the impact of the wait (and keep "producing") requires more WIP, which increases risk of and frequency of merge conflicts as well as inducing burn-out and decreasing quality of work. The bigger the Pull Requests are, the less valuable the review. The smaller the Pull Requests are, the worse the effect is on interruptions and on parallel WIP. The worse the Work/Wait ratio is - the slower the iteration speed and feedback cycles become. I.e. opportunity cost and impacts ability to deliver. Pull Requests should AT LEAST have net positive value of the expected benefits from reviews, quality increase, impact on burnout, opportunity cost, quality decrease, bugs, incidents, and Software delivery performance in general. I believe Pull Requests have a considerable net negative value, when all these aspects, unintended side effects and impact on work and people are taken into consideration. Which they should. To paraphrase Jon Arild Tørresdal: "If you and your team do not notice friction with Pull Requests, you are not moving fast enough" A way to reduce the negative impact of reviews is to strive for for a non-blocking review approach. This can be done by: * tool support (e.g. reviewing each commit individually on the reviewers own schedule - but without blocking the committer). * doing holistic review sessions of code walkthrough * doing pair programming when appropriate and meaningful. Here is a more in depth write up about removing blockers and friction: https://lnkd.in/dcBiZWdG And a bit more in depth tirade about pull requests: https://lnkd.in/d9bs77uK https://lnkd.in/dueY4Bkx

57

14 Comments

New article, just on how I use Polly for Retries in my site (and why all .NET Devs need to know and use Polly!) https://lnkd.in/exqS5JYi #polly #aspnetcore

2

It's not all non-symbolic AI... I presented today to Accord Project Technology Working Group on recent enhancements to the Template Engine and how TypeScript expressions within templates are compiled and evaluated. Accord Project uses TypeScript over Concerto types (with Concerto also compiled to TypeScript) to provide type-safe logic/calculations for templates; ensuring that a wide array of programming errors are caught at template compilation time, not at runtime. #typesafety #soundness #typescript #templating #legaltech

17

2 Comments

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.

19

1 Comment

Today's #weekendbuild series on my blog still has same topic from previous experiment to read and process 1 million rows of CSV but now using PHP. Using PHP it took around 2 - 3 seconds for reading and processing all the data which has less performance compared with Go in previous experiment (<1s). Several key findings: 1. Use plain array to hold the value of thousands or million records will caused OOM. Workaround was increase the "memory_limit" setting in PHP. 2. Instead of increasing memory limit, we could use PHP generators to hold values and it will use less significant memory. 2. Increasing "memory_limit" is basically bad practice and we should avoid it at. We should focus on optimize the application instead. Full Story:

40

3 Comments

Let's try this again, properly - now with non-paywalled link! How do you deliver great software at pace when you have limited resources and/or a small team of engineers? I propose some tips and considerations for what to do and a friendly reminder that you're not alone... https://lnkd.in/gxzDvt_r

8

The value of feedback loop on Postman collections over the years can't be understated - it just isn't visible and well understood. I mentioned the importance of this in my writing today on editors Dave Shanley and Florian Martens - I get a regular stream of these. https://lnkd.in/ecjSxZZe

13

want to learn more about fluent method chaining in c# ?

4

currently doing some research into how to test mobile apps. looking for viewpoints from native to cross platform ideally I want to understand how to get a fast tdd loop going but with balance what have you tried? what do you wish you did? what sucks? anything changed in last couple of years? #android #ios #swift #kotlin #reactNative

2

8 times out of 10 a time boxed architectural spike will drive better decisions than workshops, RFCs and C4 diagrams. Whilst I value (very much) the things on the right, there is much higher proof from working software.

15

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

I've started a long-deferred read through of Team Topologies, which speaks to some of the problems I was talking about recently around the ways "utopian" software development maxims can fail when they encounter the "topos" of an organisation's incentive and communicational structure. There's a thought-provoking section on John Sweller's 1988 breakdown of "cognitive load" into three categories ("intrinsic", "extraneous", "germane"). The thought it provoked in me was that I tend to disregard the burden of the "intrinsic" when looking for ways to reduce "extraneous" load (ways a codebase and development environment distracts me with boilerplate and arbitrary irregularity) and gain traction over "germane" problems (those particular to the domain we're working in). For me, leveraging advanced language features to eliminate boilerplate and build out a little embedded DSL that can express the problems I care about is an obvious win - I often refer to Paul Graham's maxim that you should first create the language you want to solve your problem in, then solve your problem in it. The problem with this is that it can shift extraneous load into intrinsic load, by requiring programmers who were comfortable with repetitive constructs using basic language features to familiarise themselves with much more advanced features (and the DSL's idiomatic usage of them) for the sake of eliminating what may seem to them to be quite harmless repetition. This suits me personally, because I like having an advanced model of a programming language in my head and using it creatively, but one isn't accounting properly for the distribution of cognitive load if one doesn't also take "intrinsic" load into account. I think of Golang as an intentionally low-intrinsic-load language - it has a small kernel of features, and is structured in a way that discourages higher-order abstraction over those features. If in doubt, write another for-loop! By comparison, I remember Scala adoption at TIM Group being an intensely painful experience for some of my colleagues, because it introduced so many constructs and type-level features that could be used in so many colourful ways. While I was elated by its endless opportunities for minimising extraneous load, they felt the burden of ballooning intrinsic load, and the frustration of being temporarily deskilled by the change of fundamental environment. The real art is to leverage small changes of technique and perspective, that will fit comfortably in everybody's head, to chisel away at extraneous load, until they feel that the nuts-and-bolts of their tasks are simpler than they have ever been.

12

Quote of the week - Nik Willetts, TM Forum "I think the #API story has got a little carried away with itself in terms of what the APIs themselves can do... "Simply exposing an API doesn't really do much." Indeed, this has always been true so it shouldn't have been a surprise. I was saying that at #TMF meetings and events 8 plus years ago when they were API crazy. Oh, well - better late than never I guess. Here's the bottom line #Telcos - APIs by themselves, simply represent an integration point. When you disaggregate a functional domain you increase the number of elements to integrate and manage. #Disaggregation without a high-level #abstraction for #composition and #management ensures that everything will be manually re-integrated point-to-point, in tight-coupled silos (expensive to maintain, hard to change), which is exactly what's happened. Worse, it impedes #automation and #AI initiatives. Architecture is destiny.

21

6 Comments

They told me I was mad..this I admit I am 😂 ... they said I couldn't write code... but what they didn't know was that I've been busy crafting something incredible for the past two years! 😜💻 Introducing SquaddlyHR: the HRMIS that's about to revolutionize HR management. 🚀 Check out the teaser video and see what the madness was all about! https://lnkd.in/dPvKz--h #HRMIS #SquaddlyHR #MadlyInCode #RevolutionizingHR #CodingJourney

15

2 Comments

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

Was playing around with the #Zed IDE from Zed Industries this evening. There's no Windows installer for it yet but you can compile it pretty easily. Yesterday I updated my #Rust toolchain, and with Visual Studio Community made sure the MSVC C++ build tools and Windows 11 SDK were installed. I let `cargo run` do its thing while I did other stuff, and when it eventually finished, it just launched without any build errors. Love that. Still early days though, it's not yet the most intuitive to use. I do like the docs as they are now, and also the familiar keybindings from VS Code. I wonder how easy a complete newcomer would find it though. The idea of built in #collaboration features for the IDE is great. I first saw this kind of feature many years ago in JetBrains #IntelliJ IDEA, where you could do things like viewing a colleague's session and diffing files against their local copy. I thought that was amazing! We've also seen it in recent years in Visual Studio Code and VS proper with #LiveShare. One thing these kinds of tools have issues with usually though is challenges within corporations - networking policies, proxies and firewalls, data privacy policies, etc. Having an ability to use an on-premise/local server for this would be nice too I think. As far as I understand, you can run a local collaboration version, but it's just a dev tool at the moment more than a product. The ability to follow collaborators is useful for #remotePairing or #mobProgramming. Channels with a side-by-side chat window, and note links to Markdown notes is nice. I haven't really used all the features fully, but I think it might support voice? Since COVID days I've wanted a way to combine something like Discord with Live Share or MS Teams, where you can enter a "room" with your colleagues/team, similar to being in an open office while working on-site, but now working remotely. Need a break, go over into the "coffee corner" virtual room and see what people in there are chatting or talking about - whether its collaborating on something, or just socializing. Need to have a quick team breakaway discussion, use another room/channel. Having AI as another "collaborator" in the IDE is of course nice. Interesting to see the support of multiple language model integrations too. I've recently been wanting to get back into the command line world as a primary environment, and like that it has built in vim emulation (yes... I'm finally wanting to figure out how to be a vim power user... maybe). Glad to see there's a #csharp extension, as well as an #asciidoc extension, think I might be testing those pretty soon :) Looking forward to not just playing around a bit, but trying it out on a proper project, to see how it performs. zed.dev https://lnkd.in/e5Shjx8P

2

I met up with Dave a couple of months ago in Leeds to show him the latest bit of magic I created. It's just some creative use of Terraform, DevOps and some out of the box usage of existing Python libraries, but Dave thinks this stuff is otherworldly! So we're staring into my cauldron, skimming through my book of magic, and he says something to me like, and I'm paraphrasing here... "How do you handle being so unbelievably clever and having this much knowledge and capability?" To which I replied... "You know I'm only operating at about 20% in this job right?!" Which in hindsight is a ridiculously arrogant thing to say, I didn't mean it like that. And of course, folks out there would gasp "Oh only 20% effort, pay him less!!" but my point is that most days I don't even have to try. Even when I push myself to learn something new or do something in a different, more efficient way, working in tech just isn't that difficult. For me. And I still churn output that would make most folks in tech envious. I've been trying to think about why since that day. I still don't have an answer. All I know is that I absolutely love working in this field. I love working with tech, making computers go boop boop beep beep, solving business problems, wowing people every day without much effort. Although I still don't think I'm even close to a 10x developer, those guys...wow! But it's not all sunshine and roses, believe me! Often I find being efficient and highly impactive has a downside. Business people expect more. Too much. Imagine a task takes 8 hours and I do it in 1. The next task takes 12 hours and the business complains when it's not in done in 1. This is a regular occurrence for me. Even though for someone else it might take anywhere between 4 and 16 hours to complete, because I take 2 I get grief for the delay. I try to take it as compliment that people just don't like me if they just think I'm smug, arrogant, too clever, a girly swot etc. I wouldn't have it any other way, and I think at 43 I'm finally starting to accept that and stopping dumbing myself down just to be liked.

23

5 Comments

Earlier this week, I got some lovely feedback on Learn Go with Tests (https://lnkd.in/exspPfsg) The best part is that it shows that once you get past the tutorial stage, you start to see the real benefits of TDD. So many people are stuck in the mindset that TDD is about test coverage, but the writer of this feedback has read my material and made the leap into the realm of productivity with TDD. It was very gratifying to read it. You can find the feedback here. https://lnkd.in/enCiKWqV #golang #tdd #nothumblebrag

37

3 Comments