Jasper Sprengers

Indeed, that’s the state of the art this moment, but there’s no telling how quickly it will get more sophisticated. It will not just be about stringing together code snippets based on a statistical model.

Understanding and editing generated source code will be a crucial skill in the coming years. And you always need to tell the machine what to write, which is the hardest part.

Yes indeed. For years I’ve been hearing that contemporary pop music all sounds the same, and now we have the science to back it up. People don’t value originality, it seems, or they just prefer what they know.

https://www.theguardian.com/commentisfree/2023/jul/26/taylor-swift-rules-the-airwaves-but-thats-bad-news-for-music

A likely gateway library to Scala ;-)

These component tests indeed require a Spring context (not always with an http server), but that is a one-time penalty for the entire suite. Tests aren’t noticeably slower than regular unit tests, although when measuring in millisecs they probably are. When you limit yourself to only testing the crucial scenarios that way, it is acceptable.

Thanks for your insights. The concepts of ‘unit’ and ‘integration’ are indeed confusing. Everything can be considered a unit when viewed within a hierarchy, and there is always integration of sorts at play.

In our Spring microservices landscape we focus on component tests, i.e. tests that consider a single deployable with its server runtime, but with all networked dependencies mocked, so they can run locally or in the pipeline. We don’t do integration tests.

You over-estimate me :-)
I don't have a CS degree, so I have various holes in my abilities, maths being one of them.

Yes, developers are drawn to over-engineering like moths to a flame - with similar results. (funny analogy; not mine)
I read Essentialism too a couple years ago. In a similar vein, you might also enjoy Four Thousand Weeks by Oliver Burkeman.

Thanks for your insights and I agree that security testing calls for very specific skills.
What you call a ‘software bug’ I would prefer to call a functionality defect (caused by faulty coding). Security vulnerabilities can also be introduced by code, but even more so by the way the software is configured and deployed, which may be out of the original developers’ control. All the more reason why we can’t reasonably expect them to take responsibility for all aspects of security.

I’ve bookmarked this artice! Very nice overview. I’ve used many of them already over the years. If I may add to question 17 on languages and stacks: versions matter. If they’re still at Java 8 (or lower!), it screams unmaintainable legacy, mountains of technical debt or a CTO who doesnt see the point of keeping up with the state of the art. All are red flags.

Thanks for your insights! There was a time, not so long ago, that I wrote a single unit test class for every source class, mocking out every dependency, and ending up with tests consisting of 90% tedious ‘arrange’ sections. And then I wondered why refactoring was such a pain, because the tests were so tightly bound to implementation details.

Thanks for your comment, but the link to the article is missing.

It's not all bad news, though. A lot of really difficult stuff about low level concurrency has been removed since I did the SCJP 6 several years ago. Now it's discouraged to fiddle about with the Thread methods directly and use the (scheduled) executors instead. I do consider that progress.

Well, I still do a fair bit of pooh-poohing myself, especially about such nonsensical trick questions like a public method that has the same name as its class, but also a void return type. Hence it is not a constructor. Madness!

I'll see when I get there ;-)

It’s certainly a double-edged sword. Perhaps modern photo cameras are also a good analogy: any photography course will advise you to turn off manual exposure and focus, and learn how the manual settings affect the picture. You learn a lot in the process.

Thanks for your comment. I don't think the problem is specific to younger developers. The tendency to rely less and less on our memory skills affects everybody, old and young. And it has far wider implications than coding.

Thanks for your reaction. I agree with your points.
One thing I could have highlighted in the article is that there are two sides to the coin of artistry in software. I highlighted the rigorous devotion to quality, like the way the late Stanley Kubrick used to prepare and shoot his films.
There is however also the mastery of doing the right thing instinctively, that we associate with an artist, like a jazz musician doing a solo.It takes years to master and this kind of artistry is particularly welcome in projects with a short time to market. Since you have no time or budget to entangle the spaghetti, you need folks who don't make spaghetti in the first place.

Thanks for your comment. In my current project we also use Cypress and its own mechanism for faking backend responses, which is less hassle in that it doesn't involve starting a karate server, but is more handiwork in writing the responses.
I suppose an integration test focuses on the points of integration between two or more separately deployable components of a system. Testing with a real database or between microservices would be an example. It sits higher up in the test pyramid than a component test.

Thanks for the compliment!

Thanks for your insight. I used to be an orthodox practitioner of mocking in all my unit tests, but I have revised that notion after reading the excellent Unit Testing, principles practices and patterns by Vladimir Khorikov, who offers some very sensible advice on the subject of integration testing.

Nine years later Joel wrote glowingly about the duct tape programmer:

https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/

Such a radical change of heart we call in Dutch “voortschrijdend inzicht”. ;-)

Those are valid concerns, and you're quite right that there should be such deep knowledge, at least somewhere in the organisation. I wished I had retained all the nitty-gritty details on how to do certain things that I accumulated over the years in my working memory, but sadly that's not the way the brain works. I do believe in craftsmanship and mastery, but it lies more in making sound judgement and the right intuitions than in being a treasure trove of detail.

So true. People like Steve ‘Don’t make me think’ Krug and Jakob Nielsen have been stressing the importance of usability for decades. But too many sites that stand to gain (also financially) from a great user experience look like they were built by people with no interest or experience in the matter.

Thanks for mentioning this. You're quite right. Java is easily associated with the behemoth corporation, but its roadmap may actually be more democratic than some smaller languages that you strongly associate with a single inventor.

Thanks for your insights. I notice while working remote that interruptions often take shape in DM messages that have the immediacy of a phone call in people’s expectation, i.e. not asynchronous at all compared to an email. That’s problematic.
You mention two blocks of three hours uninterrupted focus. In my experience that’s hard to achieve (dreaded meetings), but also from a concentration/productivity point of view. An hour’s full focus with ten minute admin/coffee works bettrr for me.

Interesting and varied selection, although I do think the original Gang of Four book shows its age. Many previously ubiquitous patterns (e.g. decorator) are now semi-obsolete thanks to more powerful languaged like (suprise!) Scala.

I wouldn't claim that Scala isn't well thought-out, but there's definitely a deliberate design philosophy of brevity over readability.

Good points, and I think it is very telling that a JVM language like Scala, which is much more feature-rich, has not made much of a dent in Java. It can be infamous for its unreadability because of everything you are allowed to leave out if the compiler can infer it. Not the way to go.

A little late to the party, but in the past twenty years I have observed a pernicious pattern in teams and products that started small and experienced steady growth. It's the lone wolf, highly productive coder responsible for 70% of all legacy code, who left the team. They are usually very 'inventive' (read: wheel re-inventers) not humble (in the Edsger Dijkstra sense) and never write a single line of code with the aim of explaining it to their predecessor. And unit tests are for losers, obviously.

In truth, after some ten years of experience in various Scrum settings and >20 years in IT as a developer I have become disillusioned about Scrum as a whole.

I have seen it done well in a few projects, and poorly or half-heartedly everywhere else. My own impressions:

- A focus on ceremony and standing meetings, without understanding their true purpose.

- Junior scrum masters without sufficient technical knowledge

- Inadequate quality culture. Agility demands a relentless dedication to delivering constant quality, but we get mounting technical debt and hardening sprints instead.

- Scrum is not easy. The short cadences tempt you to lose sight of the big picture and the long term. This is something that comes only with experience. Therefore you cannot expect it to work just like that in a team of juniors.

Thanks for those helpful insights. Spring adds a lot of hidden surpises in this superficially simple feature. All the more reason to test these interactions properly and in detailed integration tests against a real database.

Well balanced! Often posts about low code that are a little too jubilant about the time savings excite vehement reactions from senior developers (they may still come..). I think people don’t really fear for their jobs, but they’ve heard it all before, i.e. exaggerating the simplicity of drag and drop programming. It’s still about mitigating the accidental complexity.

I think it makes very good sense, whether or not you use a formal pull request mechanism. I find the key is to allow enough time to create some distance between the creator and the reviewer. It works for blogging as well. I never finish a post in a single sitting but let it marinate for a few days.

Fascinating read. I like the analogies with flying and language learning, which is of special interest to me, as I trained as a linguist. Becoming expert at a foreign language means you apply the rules of grammar intuitively and can no longer explain why a sentence is grammatical or not, just like native speakers. For expert programmers this means they must be able to explain their hunches well if they want to successfully coach juniors.

Planning poker sessions can be intensely frustrating and dysfunctional, I agree. But if you discard numerical tools to compare one task with the other, can you still call it estimation? At the very least any estimation will involve a greater than/smaller than comparison, which boils down to amount of effort/difficulty, hence hours.

Great article, but I beg to differ with your claim that “No one writes unreadable code on purpose”. There’s a difference between deliberately writing unreadable code, which feels like an act of sabotage and indeed very few people do if they want to hold on to their job. But there’s wilful intent and there’s neglicence. Making yourself well understood (not just in code) is hard work that people often neglect. It’s a selfish omission because it wastes other people’s time. Being Dutch myself, English doesn’t come naturally. It took hard work.

I'm suddenly reminded of a developer colleague who was also a very proficient chess player. He said something similar. Professional players don't overlook obvious opportunities and pitfalls.

Nice comparison! I always like original analogies. Yes, it's crazy how we trample on the low hanging fruit, pardon my metaphor.

Thanks for your reply. It's funny that many zealous American Christians actually have very poor knowledge of what the Bible actually says, by way of comparison. Perhaps the stronger your company professes to being Agile, the more you should challenge them to actually do it properly and make sure they know what they're talking about. Meaningful retrospectives, strong definition of done - no exceptions, excellent documentation, constant stakeholder involvement. Money talks and bullshit walks.

People take Story Point estimation as one of the pillars of Scrum, but it's not mentioned anywhere. I recognise your sentiments, but I feel less compunction now to ignore Scrum 'Masters' half my age with a fresh PSM1 telling me how to practice Agile.

'Rarely a recipe' would indeed be a more balanced title, but I also learned that bold statement generate more reads ;-)

I know the kind of work you describe, where you're adding features to a product using the same tools and techniques. It can seem that little creativity is called for, just a smooth running of the process.It's harder, but not impossible to challenge the process or the product as a whole in a novel, creative way.

It's fitting that for every programming language you have recipes for repetitive tasks that are collected into cookbooks. I've owned several of them. Management cookbooks, not so much.

Thanks! I'm reading Allen's autobiography right now. Let's say I'm very glad I'm not him, despite his wealth and fame

Thanks for your contribution. Yes, it's true that the Scrum guide leaves many details open. But sometimes illogical or counterproductive practices become so ingrained that I feel it necessary to remind people.

Interesting comparison.. I'd admit that jingles are an extremely constrained format, but then again so is much of classical music before 1900, which doesn't detract from the genius of the most famous composers of that era.

If Hibernate were simple it wouldn’t require an 800 page manual, is what I’ve been saying for years.

I’m prepared for some backlash for coming out as a Woody Allen fan, particularly given his damaged reputation. Yes, maybe he should have quit 20 years ago, but the man is my father’s age and still working.

Yes, I wish I could remove them myself. I'm the one getting the mails "Your article has received a comment" ;-)

I believe it was the late Karel Appel who said he could take a crap on a canvas and it would still sell. There's something disturbingly excremental about these rockstar painters...

You're quite right, and in saying that 'nobody' wants you to take an artist's approach to coding I was playing the devil's advocate. I have seen too many disheartening projects where there seems to be a policy to settle for the shoddiest level of quality that they can still get away with. We do need greater innovations, but that takes the courage to trust people and to invest in a bolder, more artistic approach, like PARC did in the seventies.

Thanks for your comment.
All large-scale software projects are certainly a team effort -- and so were all of Kubrick's films.
But some very impressive and seminal software was also the work of one person, especially in the seventies and eighties.
The artistic approach that I talk about has less to do with the number of people involved (although it usually takes a single visionary), but with the underlying motivation. Art always transcends mere utility.

I can imagine there's also a psychological mechanism at play when you are faced with a prospective, lucrative project that is a possible fit, but a little doubtful. You may then subconsciously overestimate the usefulness of the platform and stretch the limitations. I suppose that happens with any platform.

Thanks for your reply; it almost warrants an article in itself. My first experience with low code was when a Mendix developer was added to our team to reverse-engineer parts of a legacy php/mysql application that had to look like the rest of the monolith and speak with it through a rest api. It could be done, but I could see that the use case was far from ideal.

I think low code solutions are a logical next step in coming to terms win the massively complex integration demands of modern cloud based solutions. However, I imagine that your claims of order-of-magnitude savings and benefits will raise eyebrows and elicit the odd ‘silver bullet’ retort. How do you convince such decision makers? Do you have evidence that is more than anecdotal?

Thanks for your insights. The concept seems a bit counter-intuitive when compared to lots of older standards like wsdl, that heavily favor public services, where the consumers are unknown or outside of your control. But in many architectures it is the clients that determine what services need to be built, and therefore it’s logical to start specifying what you need (consumer) rather than what you offer (provider driven).

Thanks for this article. I think it's time to conclude that many of the common conceptions about agile are misguided and have turned into dogma: the over-emphasis on programming as a collective effort, the tedious sports analogies and the very limited actual team autonomy. What's left is going-through-the-motions ceremony.
Why still call it Agile? Sometimes a re-evaluation of ideas however constitutes a departure of principles that calls for a new name, not version two. Organizations coming to terms with their disappointment about old-school agile may not warm to the idea if all they expect is an upgrade.

Software estimates are remarkably like predicting the weather: pretty accurate for up two days while increasingly chaotic for weeks into the future. And then pretty reliable again for the distant future, which is that we'll likely go over budget ;-)