11–20 of 378 posts
CI can be a way of enforcing the simplicity of the others - it can be a way of tunneling the build process into assuredly straightforward steps and preventing individual team members from arbitrarily (or even accidentally) adding their own complications into build requirements.
Other than that, I think you are definitely on to something here.
Understanding the possible benefits and drawbacks of any solution is important. It's important in whether or not that solution is selected, but also to make sure that the implementation actually delivers those benefits.
It's very common in our industry to use "best practices" without understanding them, and therefore misapplying the solutions.
Microservices work fine in some situations, agile works fine in some situations, but until you find that you are in one of those situations trying to bend your deliverables to meet a sprint-cycle or some other nauseating jargon will cause, as you put it, over-complication or just poorly targeted effort. (It can also cause enough stress to dramatically affect your health, I know better than most)
Those moments of solidarity between product and effort are real gems that I've only recognized in hindsight.
It used to be wise to wear bell bottom jeans and perm your hair. It also used to be wise to wear colored suspenders, or pocket protectors. And shoes with lights in them, and color changing shirts.
Granted, those same weird misguided trends were probably followed by the same people who accomplished everything we have today. I think it's the effort you put into the work that determines its output, not the details of its development.
But I guess that'll look cool in our resumes.
I must say sometimes I envy our mobile developers that are a bit immune from all that.
2. I hate to say you're doing microservices "wrong" but I'd really question project structure and practices being the culprit behind the cost of doing devops with microservices.
3. This seems like an engineering fault, rather than some implicit principle behind those concepts causing more downtime.
4. How is CI a plaster on the problem of microservices? CI is useful with or without microservices.
5. Agile was always meant to be a guideline, not an end all and be all. It's meant to get your team to figure out how it wants to work, and write code before process. See: http://agilemanifesto.org/
The problems you are describing seem like big problems with your team, engineering and management. No amount of process and technology is ever going to fix a dysfunctional (sorry if that's too blunt) team. What I get from this, instead of having processes in place that make it easy to move code out, you're removing tooling to slow things down intentionally with the superficial result of "stabilizing" the entire development effort. The solution appears to be to get your team to write less code, and force management to bow down to the new reality of these "stabilizing" changes. Both of which can and sometimes should be done regardless of processes and tooling in place.
The best code is the code you don't write. But don't blame the tooling on making it easy for a team to be lazy and remove the all important characteristic of a team self-critiquing (i.e, "Do we really need this feature", "That'd be nice to have but right now we're managing to get things done.", "Did I actually test my code, was it reviewed, or am I just counting on the fact that I can shove something else out later while our redundancy systems pick up the slack?")
Off-topic note: point 5 is also the way to go with your wife/husband/girlfriend/boyfriend, your kids, your friends, etc.
We've been burned by the microservice hype, and it took a while for us to realize that most of the touted benefits are for larger organizations. These "best practices"" rarely include organizational context.