Anders Jensen

@agileklzkittens @allenholub They may understand the concept, but fail to realize the consequences. Quantifying the waste in the universal language of business (money) and making the waste due to tech debt part of the financial reporting would facilititate a different level of understanding.

@anders_hj @allenholub The problem with the term “technical debt” isn’t that businesspeople don’t understand; the problem is that they exactly understand it.

No law says that a team must immediately start on the next story after finishing the previous one. In fact, it's essential to have planned slack time in your schedule to get a smooth product-development flow. Depending on variability (e.g., how many emergencies pop up or surprises you find as you make changes), you'll need between 30% and 50% slack. The more variability, the more slack you need. Fill that time with things like learning and personal projects. Break out of the badly-done-Sprint death march.

@agileklzkittens @allenholub “Our developers estimate we lost 20% productivity during the last quarter and it will require an investment of 2000 hours to recover it. We expect an additional 20% loss and the debt to grow to 5000 hours during the next” is hard to shape favorably for malicious middle managers.

@anders_hj @allenholub With all due respect, this is a load of naive, Kent Beck Kubaya. People in management usually understand exactly what developers are saying, they just choose not to hear it because it conflicts their personal agendas and optics-shaping.

@brennhill @allenholub I think that measuring the productivity loss could convince many. Ask your developers to estimate how velocity would change if there were no tech debt, no lack of training, no suboptimal processes. My guess is that a productivity loss of more than 50% is the industry norm.

@allenholub Good luck convincing management teams that this level of slack is acceptable in a time of consolidation.

@BobSecondBrain1 @allenholub Indeed, if the target is to build up technical debt quickly, a sense of urgency is a great idea. It also effectively disincentivizes spending time to think about things and talking to customers to learn about their actual needs. Maximize that LoC per hour KPI!

@allenholub I feel like sometimes a team needs a sense of urgency.

If you have "tight deadlines," you are not working with agility. First, unless the deadline is real (e.g. tax filing deadlines and an accounting app), it simply should not exist. Made-up deadlines are a form of bullying, and there's no place for that in an effective work environment. Next, even when the deadline is real, we handle it by working small, releasing often (every few days max), and always doing the most important things first. By the time you get to your deadline, all that's left to do is optional trivia. Artificial deadlines or even "commitments" to squeeze more work out of people fly in the face of the sustainable-pace principle. Look at Menlo Innovations for an example of doing it right (read "Joy Inc").

@allenholub He is obviously not talking about cobol style data processing, but modern functional programming.

Yes! Let's discard everything we've learned about good architecture over the past 40 years and go back to big piles of functions! That'll work well 🙄. I just love impossible-to-maintain unstructured spaghetti-code monoliths. Job security, baby!

@helpermethod @jasongorman Precisely. Nonetheless, the manifesto and accompanying principles are the most reasonable definition of what agile *is*, and the abominations they hate are typically the opposite of agile.

@jasongorman Indeed, I’d really love to hear from the anti-agile crowd what exactly is wrong with agile as defined in the manifesto. Do they really want the stuff on the right more than the stuff on the left? Exactly which ones of the twelve principles do they disagree with?

@erikcorry Apparently it is also not JAVA like enough.

JavaScript is not complicated enough. github.com/tc39/proposal-…

@scotthannen Check out multimethods in e.g. clojure, which is a technique for polymorphic dispatch that can be used for discriminated unions. The technique can be implemented in other languages, although much more clumsy in some.

I suppose polymorphism could still be in the mix. A union allows for various distinct types. We can check to see which type it is, but then we have an object with a declared type. The runtime type could be anything that inherits from or implements that type. 6/6

How I think of polymorphism: An object has a declared type. Perhaps you receive an argument of type SalesOrder or IOrderValidator. The actual runtime type might be something else. It could inherit from SalesOrder or implement IOrderValidator. 1/

@Katharina01099 @allenholub That fear is often caused by time/budget pressure from the org leaving no time to use the feedback. Or lack of empowerment, feeling pressured to do things the team believes is wrong.

@anders_hj @allenholub In my experience help is needed talking to customers. Somehow a lot of teams/ orgs are afraid of feedback

Frankly, I see little or no value in team-level "Agile" coaching (including Scrum Mastering). People are smart and usually more than capable of figuring out the best way to do things (with, perhaps, a little training to get the ball rolling). Organizational coaching, however, is another matter entirely. The biggest problems don't come from the team. They come from the organization preventing the team from improving. The best way to improve the teams is to improve the organization within which they work.

@allenholub Just-in-time estimation: 1. The team spends the minimal amount of time to reach an educated guess at the most valuable activity to do next. 2. The team completes the activity. 3. Repeat

Everything is estimable! Whether that estimate is accurate enough to serve a useful purpose is another matter. It’s pretending that we can make accurate estimates, and then making bad business decisions based on that that wishing-makes-it-so attitude, that’s the problem.

@mattpocockuk Modern JS supports specifying a cause when creating an error, so it is easy to pass an error up the call stack with additional context. Something you probably want to do often with this approach. developer.mozilla.org/en-US/docs/Web…

Here's my favourite method for getting Go/Zig/Rust-like errors in TS. It's by returning custom errors from functions. - Shows right in the return type - Easy checking with instanceof - No deps required

@natessilva @mattpocockuk Maybe you are validating data from an external source.

@mattpocockuk I’m trying to think of a use case where I would need to check if a value exists in a const array - especially as it relates to enumeration. Presumably I know what values exist because I enumerated them, right?

Lots of TS devs use arrays of unique values to avoid the pitfalls of enums. But why not use a Set instead?

@KasparsDancis @austinbirch Yes! I wish there was something like it without all the suckiness of JavaScript, but my productivity in TS is excellent.

@austinbirch TypeScript is a decent compromise, and it feels like the zeitgeist is shifting toward more functional-style programming, too.

Top takeaway from writing Clojure for 10 years—dynamic typing is amazing when you want to go fast. It’s not so amazing when the codebase is old and big. You can't have your cake and eat it too.

@CFDevelop If the code is really bad, the end result is essentially a rewrite. The difference is that refactoring happens in small, releasable increments. The refactoring approach is preferred because it reduces risk and enables concurrent development and bug fixes, not because of cost.

If you find it easier to rewrite an app from scratch than fix it up, that's a you problem You need to practice refactoring until it becomes second nature Rewriting apps from scratch just because you don't know how to refactor is a ridiculous waste of time and money 💰

@mlauritse @allenholub I respectfully disagree, but I do not think twitter is the right place to argue about it. But I really do believe that querying a relational DB is a fundamentally simple operation. It is the mapping to Java classes that is hard. Same for serializing data to clients.

@anders_hj @allenholub No, it isn't. Unless you want to send trivial data, which is easy in java as well.

The more I program, the more I realize that the implementation language doesn’t matter much. As long as you’re not fighting the language to get simple stuff done, pick whatever language you like best. I’ve written a lot of code in Java, and don’t think there’s anything particularly wrong with that. I don’t really understand where all the hate comes from. That said, if I was doing a new project with a lot of logic on the back end, I'd probably go with Kotlin instead. I’m not at all a fan of the thinking that programs are just big piles of functions. We tried that 30+ years ago, and it didn’t work out very well. Consequently, I would probably pick a language that allowed for some kind of structure in the source code at the language level.

@peterrhague Most induction cooktops here in DK are 7.2kW. Max output per zone is 3.6kW for decent ones. Some are even 11kW. No need for kettles to boil water fast, just buy a decent cooktop.

I have engineers from the US straight up refuse to believe the power output of a standard UK kettle that we all have on our kitchen tops. Not only good for tea, but if you’re boiling pasta you can pre heat the water very fast.

@mlauritse @allenholub It is in data-centric, flexible languages like TypeScript or Clojure.

@anders_hj @allenholub "Simple things" :-)