In respect to sitting above the API layer and turning DTO’s to/from Domain Object’s, I’d call them “Brokers”.

FORTRAN IV was the first language I learned to program in. Punch cards!!!

Kotlin is a very easy transition, and it sorts out a ton of issues that you find in Java. Certainly easier than moving to Rust.

I’m not sure that what developers really, really need is faster programming cycles. Most teams could benefit more by controlling the process - from idea to deployed. How much technical debt is incurred because users/customers can’t prioritize features or give accurate requirements, there’s way too much WIP, features are huge, releases are huge and infrequent and the feedback cycles are far too long.

So yeah, as programmers it’s always cool to look at ways to program faster, but what’s the point in programming stuff nobody needs faster? Or programming the wrong things faster?

I’d be willing to be that if you asked any team, “What are the biggest impediments to delivering value to your users faster?”, the answer would be that you can’t cut code fast enough.

I think that defining “done” as QA tested is way better than “the code compiles”, which is essentially what most teams seem to use.

Developers need to get into the habit of not writing bugs. That’s technically the answer to all of these problems. “We have issues dealing with bugs found in the QA phase”. So stop writing bugs for QA to find, then the problem goes away.

If the attitude is “Bugs found in QA kick the feature out of the release”, then the programmers are going to find that they work all week and end up contributing nothing to the release. Maybe the release is completely empty. Hold them responsible for it. Attitudes will change.

I’d ask why I’m only getting 5 minutes at the end to ask my questions.

It seems to me that your problem is that your definition of “freeze” seems to allow fixes for QA issues. So, not a freeze at all if the idea is to give QA a chance to have a clean testing framework on Wednesday.

I see two alternatives:

• Make Tuesday a true freeze. Any defects found by QA drop that feature out of the Thursday release.

• Stop “throwing features over the wall” to QA. Make the QA testers/process part of the development team/process. Features are considered “done” and ready for submission to production only once tested. Freeze on Thursday morning with only integration testing to be done before release.

In truth, both approaches yield the same results. If programmers have to get it right by Tuesday, then they’ll need to work more closely with QA during development. Eventually, the Wednesday testing becomes little more than a rubber stamp and they’ll push to move the freeze back to Wednesday.

Most importantly it seems that in this situation the “definition of done”, has to be more than just “coding completed”.

I retired now, but I still write code for my blog. I totally prefer to write with Kotlin. Java just feels clunky to me now.