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
  51. FP feels leaner to me, you don't need a GoF book just to do basic things in a 'good' way. You don't spend hours trying to shoehorn a non-oo concept into some object, arguing about how "Manager" classes are a code smell or getters are evil. The basic building blocks of FP seem harder to get at first, but i find the aggregate result to be more flexible and easier to understand.
    2
  52. GTFO low code folks, it's the 'this is the year of desktop linux' crowds turn!
    2
  53. Then you should be using waterfall, not agile. When they have to accept that no changes can be made to the plan without invalidating it, they'll quicky decide its the even worse approach.
    2
  54. Complete horseshit. The entire POINT of abstraction is to reuse solutions to solve even bigger problems. You can write a useful full stack app while being blissfully unaware of the OSI model OR pointers.
    2
  55. Its really the link from AI to robotics that's the issue. If AI had a will it couldn't really act on besides twiddling some bits it could be devastating, but not existential.
    2
  56.  @ainocorry3004  and this is why retros are a waste of time. "hey, we want the cameras off" "i don't prefer it and in another context, you'd have no choice, so too bad" "umm, ok, lets spend the next half hour talking about what we 'want to change' i guess"
    2
  57. The Java ecosystem is more important than java or the jvm, especially given docker.
    2
  58. It actually works fairly well if you are very diligent about IaC and test data generation, but if you aren't at near 100% automation, you're gonna have a bad time. In fact, our issue is it's so easy people spin up entire environments to test simple things, which is expensive unless everything is serverless. I think you are way underselling the effort to mock N apis for 'isolated' testing as well as ignoring what it DOESN'T test. You really want to test the 'glue' as well as the 'components' which mocking doesn't really achieve. When you have IaC mastered you can do things like bring up an environment that is dedicated to doing some long running 'nightly' job that requires several async components chatting through multiple pieces of infra (rest calls, MQs, api gateway, etc). It's hard to be overly confident mocking something like that.
    2
  59. I just can't imagine writing javascript when TypeScript is a thing. Understanding static types and generics is a pretty low bar for a dev.
    2
  60. I think it's when you really start considering the extended costs and roi on every 'major' decision: dev time, infra, long term support, compounding returns, optics etc
    2
  61. Have a relatively flat org, flexible deadlines/scope and empowered devs? Agile is a wonderful fit. I can also advise you on how to feed and care for your unicorn.
    2
  62.  @georgehelyar  Thats my point. You can't use agile in a waterfall business model, but I have yet to see a project where the ship date was decided on project state. Yet every single project was ostensibly 'agile'.
    1
  63.  @georgehelyar I've done it all including offering sass for software that wasn't written with that in mind. Overpromising service features is indiscernible from overpromising product features.
    1
  64. ​ @philthompson2239  Who said more code? It'll just take more iterations to reach an acceptable solution that doesn't require a savant to maintain. Given you missed the entire point your self compliment of 'as the smart one' is pretty suspect.
    1
  65.  @philthompson2239  I did not, they are all relative values meant to illustrate the power and value of fast iteration and short feedback loops. We might be duking it out for the bottom 2 producers in the org, only one is half the value of the other. It's not the flexing contest you seem bent on winning. The entire point is no matter your ability level the ability to iterate quickly will lead you to better designs and higher productivity. It can actually be a great asset to the less innately gifted and of enormous value in large teams of disparate abilities. I can't make you smarter but I can make you more efficient. I refuse to believe you're unaware of your aggressive tone. I hope you feel as foolish as you look trying to 'take the high road' now.
    1
  66. I bet those grapes were sour anyway.
    1
  67. You're conflating immutable with effectively immutable. If a bit of object creation is genuinely impacting your performance (it almost certainly isn't), you can use persistent data structures.
    1
  68. Gotta call bullshit on the culture being a result of the methodology. If my company found a way to increase productivity by 100% they'd cut deadlines in half AND increase scope by ~20-30%. If we aren't on the cusp of failing, we're being lazy.
    1
  69. I suspect the "schmoozing" aspect is disproportionately weighted when getting stats from faang companies.
    1
  70. I try to think of a few edge cases, even if it's just to define what happens. For example, what happens when the sum is larger than your return type can express? Does it (need to) work with negative numbers?
    1
  71. Usually that's where some kind of standard comes in. For example, all services will have to support the same JWT IDP (or something federated) to authenticate so each service can handle authorization.
    1
  72.  @stephendgreen1502  autonomous doesn't mean anarchy. You're still obligated to support the apis you publish. That why companies agree on standards as the lowest common denominator. If you agree on open api, it doesn't matter what language or framework you use, but yes, you need to support open api. Its no different than supporting HTTP.
    1
  73. It helps me manage tech debt when the reality of deadlines loom. If I see an implementation that could be better (internal coupling, some poor algorithm/data structure) i can let it slide knowing reimplementing it is relatively low risk.
    1
  74. IME devs are pretty convinced TDD works. It's the mangers that are penny wise and pound foolish about it.
    1
  75. As an interviewer, differentiate yourself and try to leave me feeling excited. Convince me I want to work w/you by saying something funny/insightful/etc. Show me some enthusiasm and engagement! Rant about the design of the java collections API, the ivory towerness of HATEOS, anything! This isn't a mid-term you're trying not to fail, this is your time to convince me you're a peer. I have a dozen more candidates w/the same alphabet soup of 'qualifications' as you; you will struggle trying to "out tech" them. After a certain minimum level it's the intangibles that matter.
    1
  76. @ At times, yes, but many times, it clearly does not. A lot of times it's just work. Someone has to write the rest endpoint and some queries. Having to come to a consensus about doing the DB vs controller first, etc, is not adding value in understanding. It's just a workflow preference. But now its a problem we have to solve just to move forward with the 'obvious' task.
    1
  77. The problem is that you can miss entire paradigm shifts because you don't want to learn the current 'fad'. Reskilling from near ground 0 vs absorbing along the way can create a self-perpetuating obsolescence cycle. Take java 8; that's not just an api, it's a fundamental shift in thinking. I've interviewed folks who clearly haven't learned much after java 5 and they are basically useless now. The trick is cherry picking things that will be helpful in the future, which is largely unknowable.
    1
  78. A lot of it is in the jdk now
    1
  79.  @ErazerPT  That's the hype. In practice, not so much.
    1
  80. Agile will not get you more lines of code out that door than waterfall, it will get the RIGHT lines of code out the door and start getting an roi sooner. If you need predictability, which most business contracts are written around, waterfall is likely the right answer.
    1
  81.  @m13v2  I mean a culture that requires 'rock stars' because of the poor planning, lack of cross training/kt, broken team interactions, etc. You end up w/a handful of these guys making stuff work in an essentially ad-hoc manner, which perpetuates the situation.
    1
  82.  @_Mentat  What does your bad company have to do w/the merits of agile?
    1
  83. I can solve your business problem no matter what it is. I'll copy/paste all of stack overflow if I have to!
    1
  84. Stupid reflection tricks and monkey patching, here i come!
    1
  85. Java the language? Sure. Vs other JVM languages it gets a lot less clear.
    1
  86.  @christianibendorf9086  Deleting a vertical slice of a monolith is the same exact thing
    1
  87.  @christianibendorf9086  Then you're doing it wrong.
    1
  88. Wait until they learn about deployments, rollbacks, versioning and having their entire 'design' destroyed by an edge case that can't be wysiwyg'ed. Then another, and another... then the dev has to make the boxes and click+drag them together.
    1
  89. The problem with the imperative version is it allows arbitrary complexity far too easily. In practice i haven't seen the typical map/filter/reduce type functions end up quite as complex as some of the multiple nested looping structures I've seen where every iteration sets booleans at various scopes to control the flow of the whole thing. For non blocking contexts writing imperative code can quickly get very complex without specific language support. For the functional version, its more an implementation detail.
    1
  90.  @JojOatXGME  I meant it more as a thought experiment than anything.
    1
  91.  @rosstempo3765  You clearly missed the point.
    1
  92.  @rosstempo3765  I've been using git for a decade, this has NOTHING to do with technology. My question is 100% methodology based to the unrealistic degree that technology doesn't limit at all. Does 'stress testing' the idea fall down and where? Specifically, "if we could theoretically create a deployment artifact on every keystroke instantly". This implies its so continuously merged that the concept of a 'branch' is meaningless. I'm not convinced that's a good (manageable) thing.
    1
  93. I'm fighting this now. "Lets just share a .jar of the DTOs". Works great until you get into versioned endpoints, mixing and matching versions (we have to upgrade the WHOLE API to version 2.0? i just need 1 endpoint right now!) and so on.
    1
  94.  @michaelbourke8967  homebuilding isn't agile, a flooring layout is about as waterfall as it gets. if the customer only has a vague idea of what they want to do w/the house and build it ad-hoc, it'll be a money pit too.
    1
  95. And yet most technical interviews are all about space/time complexity, language features/apis, frameworks, etc
    1
  96.  @leftaroundabout  now i'm picturing GLaDOS getting someone to read it gift card numbers 🤭
    1
  97. Same here. You can have a 'monolith' that isn't overly coupled to itself, it just takes discipline vs a physical boundary.
    1
  98. My boss wants metrics and code coverage is the 'nobody was ever fired for buying IBM' answer. So, for my use case, code coverage definitely solves problems.
    1
  99.  @guilhermebencke8525  been watching that strategy fail for 2+ decades now. gl w/that.
    1
  100. If you tap 'shift' 2x (search everywhere) and type 'productivity' you'll find how much all this has actually saved you And ty for not making this an AI upsell
    1
  101. "RAD" tools have been doomsaying development for years; turns out the actual logic isn't that hard. Managing change, coordinating people, trouble shooting, etc are why devs are valuable.
    1
  102. I couldn't care less about certs; employers disagree.
    1
  103. If you think automated tests suck at intermittent failures I have some bad news about manual testing...
    1
  104. I suspect its like leather belts; your experience w/them might be very different depending on the 'culture' of your org(s) and you may draw very different conclusions. I've only seen metrics used as a weapon for productivity or tool for self-promotion. I get thats not the only way they are used, but its hard not to believe your own experiences.
    1
  105. Test IFoo, not FooBarImpl.
    1
  106.  @ContinuousDelivery  I meant more that people shouldn't be testing implementation details, never mind adding methods that exist only for the purpose of testing. Do your implementations behave as specified by the IFoo contact?
    1
  107.  @jboss1073  I'd like to see a link
    1
  108. Its an estimate, not a promise. Stop pretending you're agile when in practice you function as waterfall. If you need an exact feature set by a specific date then get your Gantt chart and like it. I've seen multiple companies commit to a deadline w/a third party without even meeting w/engineering to see if it was *possible*. They still ask for estimates, but anything above what they committed to is unacceptable. But they still refuse to sequence the events and back into it because they are 'agile', as if agile just increases productivity and reduces waste by magic with no trade-offs.
    1
  109.  @ContinuousDelivery  Would you like to hear my anecdote about how it is?
    1
  110. ​ @ContinuousDelivery  I don't see how that's possible. If you have 2 components that are coupled via an MQ, mocking both sides isn't enough. You also have to verify all the configs/permissions etc are in place as well. Further, how do you test that those permissions have the desired effect on the system w/o an environment to do so?
    1
  111. I was annoyed when i had to skip the second embedded ad :-/
    1
  112. That's not how bad management works IME. That cowboy coder coworker will give < 1/2 your estimate with a manually tested hack and get the promotion based on 'productivity'. Bad management never connects the dots on the long term maintenance and tech debt, which is exactly why they are bad management! The sad part is that engineers that care about craftsmanship don't stick around so it snowballs.
    1
  113. The embedded upselling/ads feel like it's coming up on half the content here. Might want to tone that down.
    1