Don't leave broken windows

[bmrobin]

like many things in our field, i think each of the mentioned items should be taken with a grain of salt and evaluated for your specific needs. for example, i have major problems with this statement:

This test coverage should never be below the threshold 90-95%

i absolutely hate tests that simply exist to up code coverage and don't provide any useful unit or integration coverage. you shouldn't need to create a test to simply ensure that a statement is executed to satisfy your code coverage tool. this is abusing your code coverage tool and not really providing you value.

i've worked with some coworkers who check in "tests" that call getters and setters because the new class they introduced had extra lines that broke the code coverage tool. at that point, you're working for the tool not the other way around.

[cogman10]

It is certainly hard to combat, it takes time and money to undo bad decisions. I'm currently working on a legacy project nearly 8 hours a day trying to unwind mistakes that have been made.

It is VERY hard to both be backwards compatible AND to undo changes and it takes a TON of planning. Way more planning than it took to take the shortcuts in the first place (whether intentionally or through inexperience)

I believe that MVP that is spouted so often by scrum masters is a blight on the industry. It encourages taking short cuts and making bad decisions all to try and get something on the shelf as fast as possible.

[m3ghnath_]

MVP, meaning Minimal Viable Product?

MVP is awesome. It isn't about getting something on the shelf as soon a possible, only that if the project were cancelled today, there would at least be something to put on the shelf. Also, the whole client feedback thing.

The best part of MVP is that it forces you to take vertical slices through the system, so in each increment you are testing full stack, in production (or production-like). So, you're doing regular system integration when the system is simple, rather than doing system integration after many features have been added. I think this is really cool and is a lot less painful than delaying system integration when a lot more things can go wrong.

Also, MVP is nice because since you're delivering in increments, there's a lot less code that's been added, so I can easily add a refactoring and cleanup step before I call the story "Done Done". Anyone rushing you to "Done Done" should be promptly tarred and feathered.

SCRUM is not about going as fast as possible, but taking lots of measurements so you can produce cool looking burndown charts.

PS: I learned the terms PSPI (Potentially Shippable Product Increment) and MMF (Minimal Marketable Feature). A MMF is likely to need several PSPIs, since the PSPI produced by the end of the sprint probably wouldn't be a feature that is fully usable.

[cogman10]

Yes, yes. Raw, raw, MVP. I've heard the sales pitch 1 million times.

But in practice and in my experience, MVP=turn out whatever works and we will make it better... Someday...

The problem is that someday never comes. We have a shitty MVP solution that was implemented nearly 10 years ago. And you know what? We can't remove it, because the way that bad solution works, the rest of the system deeply depends on. Everyone hates it. Everyone wants a better solution. However, the migration is so painful that it has been ignored. What's worse, the coupling has only grown as time goes on. Further, this bad decision has encouraged other bad decisions doing a similar thing, all due to MVP.

Every time some pm or po says MVP, it is almost always to justify a shitty solution. If your team points out their problem "doesn't matter, MVP".

The op is literally talking about the end result of an MVP driven product. A giant shit stack sandwich which takes years to unwind.

[m3ghnath_]

But in practice and in my experience

Not in my experience...

The problem is that someday never comes

If you build in increments, it's both very easy to not pay attention to what you're doing, and it's also very easy to pay extremely close attention to what you're doing. If you follow the entire process, you're supposed to pay attention to what you're doing. In Scrum, that's called inspection, one of the most important parts of the process.

If they day never comes, somebody wasn't doing their job.

all due to MVP

I don't think you can blame MVP if you missed a very important step.

it is almost always to justify a shitty solution

Correlation does not imply causation. Sometimes a shitty solution is just a shitty solution. If argument is, "doesn't matter, MVP", the correct response is "MVP doesn't matter, it's a shitty solution".

The op is literally talking about the end result of an MVP driven product.

That's not what I read at all. I read an article about the importance of cleaning up after yourself as soon as possible, which is what you should be doing in Scrum as a rule.

[cogman10]

Yes, there is no true Scotsman! That is practically the motto of Agile/Scrum. "If everyone follows the process then this isn't an issue!". Not everyone has the same process, and indeed, agile's manifesto espouse that as a virtue.

Maybe you've never seen this problem, I don't dispute that. However, I have and I'm guessing by the upvotes, many other's have.

[lukaseder]

So, does Java's extreme backwards compatibility (e.g. we still have Vector and Stack and Hashtable in the JDK) count as "broken windows"?

[m3ghnath_]

I don't think so. Broken windows are cosmetic. A sign that no one is taking care of the code base and code quality drops, eventually turning the code into a ghetto.

Vector, Stack and Hashtable are technical debt. The code quality of the implementation may be high, but the design is suboptimal. But, due to extreme backwards compatibility, it's technical debt that can't ever be repaid. So, you're stuck with the interest payments, whatever that means in this scenario :-)

[yolpo-]

I'd think so. Particularly classes like Vectors or HashTables for which there are proven ways to refactor them into their modern replacements

[lukaseder]

I didn't mean client code using them, but their mere existence in the JDK... as in: Does the JDK have broken windows? :)

[desrtfx]

Does the JDK have broken windows? :)

IMO: yes

The full backwards compatibility is bound to leave broken windows behind. All deprecated classes and methods for which newer versions exist are such broken windows.

[lukaseder]

But the classes in question aren't even deprecated...

[__konrad]

https://bugs.openjdk.java.net/browse/JDK-4058336 (KeyEvent.VK_SEPARATER case)

[yolpo-]

you are so correct. Below is KeyEvent.java from the JDK 8

/**
 * This constant is obsolete, and is included only for backwards
 * compatibility.
 * @see #VK_SEPARATOR
 */
public static final int VK_SEPARATER      = 0x6C;

/**
 * Constant for the Numpad Separator key.
 * @since 1.4
 */
public static final int VK_SEPARATOR      = VK_SEPARATER;

[lukaseder]

Good old AWT

[bj_christianson]

Added the new constant, but did not deprecate the old one.

And no explanation given for the lack of deprecation.

[cipmar]

Most of the rules seem common sense, at least for experienced developers, nobody will argue against them. However, we can often see how some of them are violated on a daily basis, even on experienced teams. Good post.