Surely "don't trust everything you read on the Internet" is just a given at this point, especially if it originates on Twitter.
2,244 karma · joined April 25, 2012
That being the case, I imagine that sometimes these things get lost in translation in large corporations and don't literally mean what you think they mean.
I imagine what they are looking for is someone who can demonstrate how their 12+ years experience can be applied to that technology.
This is why I like the "Rule of three"[1]. Only once you've done it three times will you truly begin to understand what the abstraction might need to look like.
Why?
That "Micro Service Instance" is not a microservice, it's an Enterprise Service Bus (ESB), aka the Egregious Spaghetti Box.
That's aside from the fact that relational data belongs in a relational database.
I really can't imagine it being a single instance, that just does not make any sense.
How do you propose that queue is prioritised and consumed by the development team?
It works to an extent, but then someone somewhere usually has an abstracted concept of priority, otherwise you end up with priority as per the "highest paid person's opinion".
What businesses want is a way to be able to track progress and communicate priority.
The difficulty for the the business is how they communicate their priority to you, that's what the priority field is for, it's a way for the person raising the issue to supply a way to communicate how important an issue is to you.
The position in the queue is how you (and presumably your team) should decide what order to tackle the work in.
The final point is the solution to the problem is to create another system for issues, which goes against the point that says "every team must have a single ordered queue of tasks".
I find it interesting that the solution to, in their own words, "One of my life’s traumas" is to add another issue tracking tool.
Are we trying to fix the right problem?
I think there's always been a lot to be said for good, static sites, and there still is.
It's not even exclusive to distributed systems, most computer systems look like this when you actually think about it.
Consider what an application would look like if you mapped out each service and object, it would easily look as complex.
This isn't a new concept, we've had the idea that everything in computing could be represented by little computers communicating with each other since the 60s, Alan Kay called it "object-oriented programming".
The only difference is between the 60s and now, is that instead of mainframes we have platforms, so now we can actually have "little computers communicating with each other".
https://wade.be/2016/01/30/welcome-to-jekyll.html
Can’t get any easier, cheaper or lazier than that.
If this was true, then search.com would be more important than google.com right?
When I tried to find a web page from a certain date a few months ago, it was almost impossible to find.
I actually think Internet Explorer used to have quite a good history. That's what we need, not better tabs management.
However, the sections on dealing with external triggers and pacts are pretty practical advice in the current climate.
The commentary is what makes this interesting, not the content of the article.
Here's some examples: - http://www.lingscars.com/images/pdf/icoletter.pdf - https://nocookielaw.com/
The rest of the article goes on to deliver, frankly an opinionated way for young developers to act to maximise on their time.
I really think this is short sighted and honestly all of that can be boiled down to having the ability to scale yourself effectively.
It’s basically about Kaizen, continuous improvement, but perhaps ironically that takes time.
The manifesto itself says:
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
I get the impression as to what you're witnessing is, water-scrum-fall...
See: https://i.imgur.com/6eqk7eF.png
On the flip-side, your team of renegades managed to deliver in 4 weeks, while being great, I would question how sustainable that is. Also I get the impression they had skin in the game.
> what I see today in modern practice looks nothing like what was intended
You're 100% right. I don't think it means agile should die, I think it means people have forgot what it set out to do.
Scrum existed before agile and is a framework to help people work in an agile way. However people have got too wrapped up in the orthodoxy and have forgot what agile is actually about.
My mantra is simple: Release early, release often, listen to the customer
When I first got into software development it was because of open source software. On the SourceForge website, under the “Promoting your project” section, you’ll see it say “Release early, release often. Frequent releases state loudly that your project is alive”.
Years later, I learned that this philosophy was popularised by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar. Only, his version also says “listen to the customer”, an important part that’s all too easy to forget.
Vendor lock in is essentially that it’s more effort than you’re able to afford, in terms of time and cost.
There's always a tradeoff, but being all in on a vendor isn't necessarily a bad thing. Embracing a platform and the services they have to offer is how you get the most out it.
Whenever you pick a technology or service, you need to employ an ongoing effort rather than waiting until it's too late to do a one-time effort.
This is true with any choice of technology, whether your rolling your own or using SaSS, an on-going effort is required to avoid being locked in.
Nobody would describe a plain shirt as a shirt without stripes unless it’s within that context.
If it’s important enough to write a todo then it’s probably worth doing and prioritising against everything else.