• 48 Posts
  • 274 Comments
Joined 11 months ago
cake
Cake day: July 29th, 2023

help-circle






  • the whole point of agile is to be short term

    Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.

    This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

    Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.


  • The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

    I think you got it entirely backwards.

    The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.

    The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.



  • I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

    The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.

    It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.





  • it’s about deploying multiple versions of software to development and production environments.

    What do you think a package is used for? I mean, what do you think “delivery” in “continuous delivery” means, and what’s it’s relationship with the deployment stage?

    Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

    https://wiki.debian.org/DebianAlternatives

    Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.













  • This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.

    I think this principle might fly under some people’s radar because it has been a solved problem for decades.

    Even Makefiles don’t require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE flag.

    After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don’t require it. The ones linked with IDEs already provide GUIs designed with this in mind.





  • When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

    It’s one thing to claim that tests need time to run.

    It’s an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

    More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.