61–70 of 115 posts
I get to a working version of the feature quicker. From that, I get more insights. Sometimes I even realize that the simple and dumb version is good enough already.
I would say that this is the single most efficient rule/heuristic I have for making sure my productivity stays high.
I think this advice is a little vague and therefore easy to get wrong. My approach converged to something that can be understood as a form of progressive enhancement, so basically providing the simplest usable version of a given feature, bearing in mind that eventually you'll have to expand it to what was originally requested - but that's all in separate tickets. Some examples: Six different payment processors? Start…
Your examples are very reasonable, and somewhat at odds if what the author is advising I think. As you say the advice is vague but I suspect it's also just fundamentally flawed. There are very few real world scenarios where "just make it work" is a good approach to tackle engineering problems that require senior developers (read; developers with extensive experience in the related problem domain) in the first place.…
Sort of insidious, but stakeholders are happy because they get their needs catered to in a timely manner.
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company.
So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API that the C# component was using for communicating with our Java blob.
Last thing we were thinking about before I left was... NOT to rewrite the C# parts in Java properly, but to wrap all of it in a thin Java layer that we could use as an adapter when the API inevitably changed.
An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes. Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at fir…
Earlier quoted context omitted.
> If you're unfamiliar with the problem space, just bang away at it. > Write that god object, that 500 line function, hardcode all the things. > You wouldn't be able to come up with useful abstractions so don't > bother trying. I take your point about this applying to the context of prototyping. But speaking universally, I'm trying to explain a third way in which you don't try to pick abstractions or apply hyped patt…
Then I disagree with you. If you don't know how to build a static asset server or a Vulkan renderer or an arena allocator at all , then you don't know how to build those things conservatively either. The first pass in situations you have never been in before is always going to be completely worthless. You do not have any tacit knowledge of the problem space. Your prototype is strictly to gain that tacit knowledge, ze…
You can write code conservatively by avoiding higher-level abstractions and preferring boring technologies. If you look at the engineering indulgences discussed within the article, they are all things that you can conservatively avoid without any prior understanding of the problem.
The intuition behind this approach is described within Sandi Metz's "The Wrong Abstraction" talk (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction).
I also disagree that zero mental stamina should be spent on anyone that isn't between the chair and the keyboard. If you're a software engineer working within a company, the approach should generally be understandable by your team at least.
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
A "softer" way of handling this is to assign the prototyping / PoC development to a different team. The tribality / process worship / power dynamics between teams virtually guarantee that no code will be reused between the PoC and prod.
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
--Fred Brooks, The Mythical Man Month, Ch. 12.
Earlier quoted context omitted.
That seems like a failure of management.
Well, if one's management consistently fails in a predictable way that one can adapt to, one should probably adapt to it regardless of whether they believe it's a failure.