51–60 of 93 posts
Ideally your documentation is tightly integrated with your tests too, then it will be done as well and won't go stale.
Earlier quoted context omitted.
Good call. Software is a living organism, or it is dying. Just as a practical observed matter of how it actually works out. There are a few exceptions, but few indeed.
Firmware is also software and as far as I can estimate it never got updated after release in the vast majority of cases up until like a decade ago. Think BIOS/vacuum cleaner/shaver/toothbrush/alarm clock/dumbphone/non-smart TV/airplane kitchen equipment/medical diagnostics devices/PLC's that control most of the entire world's infrastructure and so on. It's entirely possible and very common to have an actual "final" s…
Updateability is the defining advantage of software over pure hardware solutions. If you don't use the advantage then you are stuck with just all the disadvantages.
All of those things should be added. I would argue they take far more than 1%. They're easily 10, 20 maybe 30 or 40% of the work. Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends when done but often gets thrown out because we schedule our work for 'MVP and yeet' where 'minimum' is de…
Having worked in multiple environments with differing code quality standards, it's pretty apparent how both "minimum and yeet" and "completion or bust" fail. "Minimum and yeet" works surprisingly well if you have unsolvable debates on customer value, options to yank the feature if it sucks, and generally competent engineers. If you are really good at yanking the feature when it sucks - you may even be able to get awa…
Automated testing FTW. Then you can change and refactor and extend all day, as long as the tests are all green, you are golden.
Earlier quoted context omitted.
Having worked in multiple environments with differing code quality standards, it's pretty apparent how both "minimum and yeet" and "completion or bust" fail. "Minimum and yeet" works surprisingly well if you have unsolvable debates on customer value, options to yank the feature if it sucks, and generally competent engineers. If you are really good at yanking the feature when it sucks - you may even be able to get awa…
I love this whole post! Small add: "generally competent engineers" can sometimes (almost) inline most of the code completeness details for cheap, reducing their cost greatly. Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though.
And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time.
Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
All of those things should be added. I would argue they take far more than 1%. They're easily 10, 20 maybe 30 or 40% of the work. Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends when done but often gets thrown out because we schedule our work for 'MVP and yeet' where 'minimum' is de…
Not to mention a good AT coverage - it can easily take 20% of project time, and often much more.
(The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)
None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to b…
And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.
The article is, on its face, completely wrong. > This last 1% [is] what separates a product that might not eventually fail from one that will eventually fail. Then proceeds to list a dozen different types of instrumentation, dashboards, and documentation. I don't know about anyone else here but I've working on many, many successful software projects that have made their owners many millions of dollars with out-of-dat…
Considering automated testing as "technical debt" is why there is so much crap out there.
Earlier quoted context omitted.
Yes, I initially thought that the OP was someone resubmitting that post, in fact
Interesting, I didn't even see this the other day. Guess it's a common sentiment :)
I thought this was a direct response to my post.
I will do these for myself and my team but only if management recognizes this as work. If my performance review comes back with a low rating despite me having done this work, I am not going to do this any longer. Management can feel free to deal with consequences.
And this is the crux of a lot of software developer angst. Most management doesn't know the benefit of code quality (refactoring), unit tests, metrics/monitoring, security, etc. and will push back against the extra work they take. Good software developers do know the benefit of those things. They resist the management's efforts to ignore those things. In the end, the software developer often give in because they know…
Those don't sound like 1%. They sound like a lot more than that. Which is why they don't get done. Who has the time?
That's the difference between professional software engineering and just hacking something quick in your free time.
You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software any different.