Comments by "" (@adambickford8720) on "Continuous Delivery" channel.

  1. Most companies don't want 'agile', they want high throughput waterfall; they already have the scope, date and resources decided. They just think agile will somehow magically increase productivity (and blame the devs when it doesn't).
    454
  2. I've found it slows me down and traditional static analysis tools are still better. They are faster and don't hallucinate.
    55
  3. Way too much emphasis on parallelization. It's like dunking on the OO 'reuse' argument that just doesn't work beyond the most basic stuff. That doesn't mean OO is useless, just that aspect as oversold.
    41
  4. The problem I've seen is over time you end up with a team where nobody was involved in 'building' it, but they are saddled with running it. With a low-quality system the "devs" essentially turn into ops, so they quit. Then the next generation of "devs" get bait-and-switched, and so on.
    31
  5. IME the onus is on the wannabe dev to bootstrap themselves. Even then, if you have the education/certification, you'll be lowballed w/o relevant experience. Thing is, once you have this experience, you're suddenly worth ~30% more than when you started but they don't recognize your actual market value. Seems crazy to me the broken interview/hiring process wasn't cited. I've seen great devs passed on because they couldn't rattle off a CS algorithm from memory.
    13
  6. A nice perk of specific versions is you can add known vulnerability analysis to the ci/cd. I like to do version upgrades as their own unit of work; since it 'isn't supposed to change anything' it should be obvious what the root cause is.
    13
  7. What dogmatic BS. Saying always is as naive as saying never. The bottom line is coming to consensus always takes longer than not but doesn't always add value. Certainly, it does some of the time, which is when we should pair. Breaking up and coordinating the work is an overhead working alone doesn't require. Sometimes it's worth it, sometimes the coordination is almost as much effort as the work.
    11
  8.  @gezenews  Being hired as an 'app dev' and your whole day is refreshing AMIs, updating security policies and credentials, rotating certs, fixing the ci/cd, updating vulnerable app code/dependencies, troubleshooting/restarting services, etc.
    11
  9. Almost everything that a 'platform' brings is taken away by the inability to google it, ramp up new users, etc. even if it's good. I've never seen a good one irl.
    10
  10. That manager is rewarded on short term deliverables, not long-term maintenance, and it's reflected in the software akin to Conway's law. He'll be promoted, cuz he's obviously 'effective', and eventually some other sucker will take the fall when the system is found to be 'unmaintainable'.
    10
  11. That's the hype. In practice, there really isn't a ton of accidental complexity and these snowflake abstractions are hinderances.
    8
  12. I just got paid and yet i'm already broke. See?
    8
  13. I worked at a fortune 100 company with a forced 'platform' and it was terrible. Forced upgrades that could just blow up an entire sprint with breaking changes, yet you can't get things like a modern version of java on the platform. Some terrible leaky yaml mess over the real cloud apis, only you can't google anything and slower, undocumented bug fixes. A new cloud service that solves your problem? Not for at least a year for the 'platform team' to add another bad abstraction over the latest cloud services, assuming they think you need it and they feel like supporting it. All while touting innovation and autonomy.
    8
  14.  @thought-provoker  If you need that level of predictability then build it before you sell it or waterfall it out to the smallest detail. Otherwise, you're not solving an agile problem and your failures aren't because of the devs or agile. Its a management failure. Predictability always comes at the cost of throughput. If you want predictability i'll tell you next month when I really think it'll be next week. I'm guessing you don't like that answer because you don't want 'waste' either. Pick your poison, cuz thats how reality works.
    7
  15.  @BryonLape  And having to sift through all the resumes where they think sticking a json blob in mongo during the todo tutorial is 'full stack'. I see guys 2 years out of school applying for 'senior dev' positions. Yeah, no.
    6
  16. Most developers aren't nearly as clever as they think they are, but that doesn't stop them from making a mess of even trivial things. However, in an async world they are far less brave as the 'complexity budget' is largely spent. I've found that actually makes things easier as you're tackling essential complexity, which is researchable, vs some wannabe 'architect's layer on top of JPA (or whatever).
    6
  17. FYI multi clipboard is built into windows; win+V to select from the list and paste
    6
  18. Just like OOP there's 99% chance you don't have a problem that warrants microservices but it'll be the defacto solution anyway.
    6
  19. I'm at an org where devs are reprimanded for addressing tech issues that 'werent asked for' in the ticket even if they only take a couple hours and are objectively better. They also treat devs as coding bandwidth; their advice is almost never taken and any deviation from the glorious scrum plan is stomped out vigorously with a lecture on priorities. Of course, anything that doesn't go to plan is blamed on the devs as it's assumed the plan 'should' have worked. I can tell you without hesitation that the awful environment kills engagement and therefore productivity/quality. Devs have to take the top ticket (can't even have agency within the sprint as it's been decided for you) so are happy to just plug away at tickets w/no cares given to the actual impact or value.
    6
  20. I worked with a team that had multiple 'microservices' that had to share a lib that defines the DTO's between them. You had to update the DTO project, then update all the 'microservices' to depended on it, then all be deployed together. And no, you couldn't just upgrade 'some' of the endpoints, there was one jar to rule them all. The hilarious part? It was the same team maintaining all of the 'microservices'. All they did in practice was add a bunch of infra to support network vs in memory calls.
    6
  21.  @georgehelyar  Yet everyone is really doing 'to hours' conversions in reality. Until project deadlines are measured in story points instead of schedules and dates, they always will.
    5
  22.  @stojadinovicp  That's just not true; this is not a silver bullet. Sometimes large frameworks break things with no 'intermediary' path, its all or nothing. For example, Spring R2DBC changed their DB client which broke every single one of our DAOs. The 2 clients can't co-exist so 'branching by abstraction' isn't really an option (this involves DB txns, so even stupid class loader tricks won't save you). Cybersecurity is demanding that upgrade, yet the team still has to deliver on the existing roadmap.
    5
  23. The market for your employer's good/service is distinct from the labor market that creates it. Don't think for a second it provides safety, leverage, etc. Do your best to build 'portable' skills. Long hours working on your company's proprietary webstack/orm is a fast track to nowhere and leaves you uniquely qualified for an unfair supply/demand relationship.
    5
  24.    No, it's my opinion based on my direct experience with such systems. Correcting me on your misunderstanding of the problem sounds exactly like what a platform engineer would say though ;)
    4
  25. It's very subtle. In the 'bad' example he's using the implementation by looking at the `.length` property of the backing field vs the `length()` method. Same with the 'get' example: in the 'bad' case he's directly accessing the array via index instead of the public api i.e. the `get(i)` method. Technically a `StringList` doesn't have to be backed by an array, even if it's the obvious implementation. However, if you couple to the array it will break when evolving.
    4
  26. Taken to an extreme this would end up with the whole team 'live editing' the entire code base. Even if unit/integration test were instant (could theoretically create a deployment artifact on every keystroke) I don't think this would work w/o some kind of 'check pointing'? Where's the 'sweet spot'?
    4
  27. 1.0 is always going to be wrong. Start with the cheapest possible solution so you can more readily throw it away when you better understand the problem.
    4
  28.  @kevinfleischer2049  If you specify crap, expect crap to be delivered.
    4
  29. Every single company I've worked for knows what features they want by what date(plus whatever features come up in the interim). Every single one of them also claimed to be agile.
    4
  30. Its easier to add code than to change it. It'll be easier to create it when needed than conform it to what was predicted.
    4
  31. And that a failing of management, not agile. Sadly, very few business activities genuinely support agile.
    4
  32. Is it really more configurable though? Every major IDE allows you to write plug-ins to do anything you could imagine. Sure, it's a pretty steep learning curve but the flexibility is there.
    3
  33. If you're 5x smarter but I can iterate 10x faster i'll still be twice as valuable to the company... AND the jr devs understand my solution ;)
    3
  34. Thats how it started life, after j++, j# and a bunch of shady illegal stuff to sabotage java (they paid millions in lawsuits)
    3
  35.  @puntoycoma47  A static analysis tool actually understands what is going on. They deterministically make changes that were created by the authors of the tool. Their behavior is well defined and deterministic. The downside is its fairly tricky to pull off and labor intensive. Got a new language feature? Better update your tool as it could literally be broken. IDEs and LSP are examples of real time tools that do this. AI tools are just pattern matching that happens to work if you are close enough to what it was trained on. It doesn't understand a 'loop', it just knows that the pattern of creating a collection and loop followed by api calls is a common string of tokens, so offers that. This is why it can 'read your mind' when doing CS homework but chokes on anything even slightly novel. The plus side is as it sees new features in training data it will 'learn' them. Of course, it's just spewing whatever pattern it sees, that sometimes compiles
    3
  36. "We're almost ready for 1.0, just need to add tests and security". --Every death march project ever
    3
  37.  @gezenews  You really can't. Nobody is honest about it actually being an ops/maintenance gig because its hard enough to get devs as it is. IMO its all about the middle-mangers. If everyone can do everything, they don't have to manage or coordinate. Just complain the 'devs' aren't 'agile' enough.
    3
  38. So essential I've never seen it used in practice beyond experiments.
    3
  39. If agile didn't work, you didn't use enough. (the process isn't the goal!)
    3
  40. I couldn't find a single atheist at my church.
    2
  41. Context is king. Even everything dave is suggesting is a bad choice if the app is being maintained by nothing but junior devs (yes, this happens). They won't understand the tradeoffs and unknowingly compromise the design, losing all of the advantages while keeping the disadvantages and compounding them. A 'VB' solution might actually be the right call.
    2
  42. ​ @ContinuousDelivery  I mean with little to no mentoring. The senior devs were "too busy" on "more important" projects. Yes, this happens. I've seen jr devs handed a 'simple' java MVC rich client w/o understanding OO. The first thing they did was start making things static to "gain access" as DI was 'too complicated and overkill'. That's far worse to me than just having it be either case consistently. I'd rather maintain a VB app clearly written by juniors than cargo culting juniors gone wrong, even if it "shouldn't have".
    2
  43. "Done right" or "Done right now"? Your boss will choose the former and be promoted before the later needs to be paid back.
    2
  44. How do you replay events through an evolving system? For example, some subset of messages are processed by api v1, others by v2, etc. How do you handle the bookkeeping to 'recreate' reality? Is there a system that tracks this kind of meta data?
    2
  45. ​ @stephendgreen1502  correct, there are definitely 'cross cutting' concerns that don't work in full autonomy. Security is one of the cases. There are others. For example, you likely should all be using some kind of standard for tracing/logging or trying to troubleshoot a request across services will be near impossible. If you have many disparate systems to monitor app health, that can be an issue too. this is usually where some kind of 'platform engineering' comes into play. the systems have to be coupled to work, the challenge is doing the minimal amount.
    2
  46. ​ @andsnpl  Yes. I was told by our director explicitly: "Stop w/the science project and ship some damn code. I'd rather have a broken app than an incomplete one". I'm guessing its easier to throw the devs under the bus for low quality where incomplete is seen as mismanaged. Bad leadership is often bad in every respect. The best part is we're replacing an app widely considered unmaintainable, which also has no tests!
    2
  47. ​ @andrealaforgia  Call it what you will, but most contracts define what should be implemented, by when and with a known budget. In fact, they usually spell out exactly what happens when those things don't happen. Waterfall may not be the answer in this very common case, but agile definitely isn't either.
    2
  48. Any place that has a lot of 'rock stars' is almost certainly dysfunctional.
    2
  49. I use intellij because I don't want to manage a bunch of plugins. VS Code is definitely improving faster though, so I'll likely switch at some point.
    2
  50. The problem space largely drives the 'shape' of the solution. Some solutions are easier to express in one language vs another. That metric is super flawed to me. Different languages have pros/cons depending on the problem we're solving. This 'function point metric' problem is a contrived problem space that's just not useful. Lets see how long it takes to create the N 'function points' required for, say, a distributed cache. Are you really going to do that in VB? Why not? I mean golly, it's #4!
    2