I'm not really a Scrum aficionado. Actually I'm pretty far from calling myself that way ;) But I can still remember the moment years ago when I was reading through Scrum Guide & some accompanying materials and I've found out a term that has really caught my attention: "the quality built-in"It may look inconspicuous, but in fact it's a very powerful concept. It can be described with the following statements: once the product has a desired level of quality, the effort to keep it there (at that level) is very low but continuousonce the product's quality has decreased, getting it…
All posts in technical debt
What can we say about the characteristics of lava flow (no metaphors YET, I refer to RL lava)? it's practically impossible to stop/revert lava flow, it can either continue in the current "channel" or get routed in a new one(s)if there's no clear channel/route, lava will find its way in an uncontrollable mannerlava doesn't just pass by, it marks its way along the whole path with fire & razed groundNeat, but how does it correspond to software architecture? Lava flow represents the utilized "capacity" of development team. Developers will create code regardless of whether architecture is…
TL;DR I keep seeing the term "Technical Debt" used as some sort of justification for bad engineering: "we had to pick our battles", "it will be fixed when it's time", "it's what happens to all apps with time, live with that". This is not correct though: there's a very clear difference (of awareness & in-depth understanding of consequences) between these two & what is more interesting - there's also a huge gap between both consequences & price to pay if you want to fix them. Technical Debt (TD) seems to be…
TL;DR If you see that teams "reject" the (part of) codebase, working with it lowers their engagement level, they have neither energy nor will to tackle its challenges, it's very rarely the matter of codebase's size. Sober-minded engineers just do not want to have anything to do with crappy code, especially if they don't feel responsible for its "crappiness". What they need is not their nametags pinned to particular mounds of dung, but a viable, credible & feasible strategy to dispose it. Code ownership problem is almost as old as teaming in software engineering. At…
Do you recognize any of the following scenarios? Continuous influx of requirements put you into permanent death-march - you're always struggling against deadlines, there's never time for refactoring, unit testing, etc. Firefighting is your bread'n'butter - issues pop up on daily basis here & there, so there's never time to fix (or even locate) the root cause or go through thorough post mortem. You've reached the point when each quantum of work you do is burdened with enormous "tax" - hence huge efforts result in dripping value. There are just too many dependencies, architecture is too coupled, procedures…
Disclaimer: the idea of immutable code ain't mine - I've read/heard about it somewhere (can't recall precisely ;/) some time ago & it sticked with me. Code maintenance is already a huge problem & it won't get any better by itself. Software is everywhere - even mundane, basic everyday tools get "digital" & ... flawed. Two, three years ago I was encountering bugs (in software I use) occasionally (well, except of Windows itself ;>), now it's a daily bread'n'butter - I don't even have patience to report them. Bad news is that not only many new ones appear, but…