978 karma · joined November 11, 2018
So, let me get this straight - it’s quite likely a bike gets stolen and this experience, as shared with me, has led you to take precautions.
My precaution being not taking the bike some times and to some places.
How many times have you have a car stolen over that same time period?
I had two strollers stolen from my backyard while at home last year… it’s kinda crazy over here!
I’ve got a bike AND a car, I still take the car on certain trips where the bike would make more sense logistically because it feels like 50/50 it’ll get stolen.
I’m talking “desired state” here and how to fulfill it - not “various states to switch between”.
With nix(os) I feel you treat a machine more like an appliance!
Nix is absolutely awesome in that regard.
Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going.
Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure.
Nix is in many ways easy to use “on the surface” but quickly becomes hairy as you dive deeper.
Just my 2c having spent quite some time with all three.
It took me way too long to realize this option - many builds using miniture casings with cooling issues later, when buying large 2U cases with 120mm fan walls is the ticket.
You have to focus on actual value, and empire-building is kept to a minimum.
They need to be treated differently as your driver probably differs by miles from what drives my team of system developers. For someone in sales, maybe with compensation in the form of commission you have clear metrics every month. I can have guys sit around and think for a couple of months with the benefit of us staying agile and malleable two years from now. This is where the disciplines differ by a lot and must be treated and measured differently.
We self-host, but they have a GA cloud offering now. [1]
As long as you use js/ts, go, python, php or java that is. For some jobs we wrap process execution - e.g running a powershell command.
In Sweden we call “sale” a “realization”, meaning consumers pay the true cost without markup. I always say we’re realizing the wrong way - cost should quadruple for every H&M item we buy, and the money should go to enforcement of clean production.
Hard sell, but eventually a must; cut profit and increase price at the same time.
The push for Lean (by way of Agile) has been more pronounced within IT/tech than any other non-manufacturing industry that I know. We’ve been collecting metrics for as long as I can remember, and reported them.
What is interesting here is that studies out there on knowledge work indicate that most of it is wasteful.
What you need to have for a team to perform is clarity, relevant competency and freedom to do the work - all of which are managements real job to put in place. This can be hard to grasp coming from sales; the value of flow, the detrimental effect deadlines and hard estimates have on team performance.
The individual team need to identify what they can do to become better and they should measure this. But not in any way should we put this relative to other teams metrics.
For example: one team might frequently end up in wait state due to a stakeholder or customer, when touching specific parts of the code/system. This usually leads to the team picking up new work while waiting, increasing WIP and context switching.
Another team have to deal with a lot of legacy code within their domain, that doesn’t build or test well. This have to be prioritized if this is important software or else this team will be a hog for eternity.
Measuring these things is important, and most definitely possible - you just have to understand the profession.
Can we identify a good meeting and "turn up the good"? Much harder, and requires actual leadership.
As it is such a meat grinder I can only hope it gets replaced with AI as I’ve seen many in sales not feeling well.
Trying to imprint sales principles on engineering or any other knowledge profession is what leads to horrible organizations filled with unhealthy practices and people.
Something Dr Crusher would come up with.
It makes a distant future where we quickly engineer a fix and inject it seem almost plausible.
I’m in such a situation as we speak, and I’ve worked with low/no code workflow tools for more than a decade.
I’ve been part in building two: one BPM(N) workflow based and one graph-based data-modeling, form-building, event-sourced nightmare (like Alan or structr [1], both probably 10 years old by now, btw) - it goes for a great sales pitch but never touches on the finer points of maintaining and iterating on systems over time; a.k.a ownership!
Coding is usually not the issue, especially in business settings. Rather it’s about accumulating domain knowledge and expertise and figuring out boundaries.
It’s perhaps even more about owning the end results over time.
There’s a sort of quasi-competency built up around tools like this - you still need to understand how to build and govern systems, which is the hard part.
You end up with non-system thinkers that can build opaque stuff in a DSL. This ends badly.
Yeah, I’ve been around. Also blockchain will change everything. ;)
What happens when stuff evolves and becomes integrated?
I’ve, several times, seen the result of tangled lc/nc stuff gone production critical and… it becomes an unmaintainable mess that no one wants to touch. This becomes a massive roadblock for agility and change down the line.
A simple, discrete, crud app that could have been an xls - sure. Great for PoC and demos; horrible in a live business setting. IME.
Basically we’ll end up in a totalitarian society governed by an AI.
That train of thought escalated quickly.
You need to create value continously or fall back to UBI.
Just something to play around with. :)
Software is more like keeping quicksand in your hands.
The construction of houses take mature engineering principles and calculations of a physical world to create buildings standing for centuries.
Most (not all) changes after construction is veneer - on the surface and replacing of bits 1:1.
Software on the other hand need constant attention and massive changes to the very foundation is not uncommon. It might go as deep as a change in hardware, say moving from one arch to another, or changing of the software architecture such as moving to a distributed, eventually consistent persistence layer or vice versa.
It’s not like concrete stops functioning if you don’t keep touching it either. Don’t get me started on build pipelines, testing, integrations etc etc
And next up: product! Yesterday we thought it was a new empire state building buuuut it turned out we need to build a modern day coliseum.
Followed by “project management” - this may be the most obvious sign that we’re off in comparison. A building need project management! Software on the other hand is often ruined by it, as software is supposed to be malleable.
One is soft, the other is hard.
Trying to liken software production to building construction is something I’ve seen create various problems in this field of ours for a long time.
Using a db gives you a better way of modifying meta data in batches which might be required at scale. It also makes it possible for tooling to query stuff quickly and do operations such as setting consul intentions, register something in an api gateway or other surrounding config tasks.
The pipelines we built checked out complete subgraphs from an api and generated json that referenced versioned TF modules and committed these to a service repo.
Thought about open-sourcing for a long time but never could get the go from legal. :(
This is very cool though!
Or if you’re a really small company - sure. You should probably rely on SaaS mainly.
I would say many companies fall outside of these categories though and could potentially both save money and gain performance staying on-prem.
I know my current employer does, and we’re seriously looking at moving back to on-prem/co-lo.
Poor management requires boxes.
Better management actually care and help employees perform and improve.
In the end it’s about culture.
You work on stimulating things and get paid what you accept.
You’ll have a yearly review where you have your say, and pay can be increased if employer think it’s worth it.
Titles are problematic in teams working to produce good stuff!
We should compare ourselves to athletes more than the MBA powerpoint version of a company.
I hear Tom Brady is a legend - is he an S10 quarterback? Senior quarterback? Or just a quarterback with high a salary based on performance?
I believe levels are instruments for managers not employees.
Here’s some more data[1].
You can quite easily find more research.
It’s clear to me that the science is inconclusive regarding benefits, at best.
We’ve evolved by eating and having complex processes take place inside our bodies to break down the food.
My personal take is that these processes in them selves can be important, and bypassing them doesn’t necessarily have positive outcomes.
[0] https://ki.se/forskning/vallagad-mat-battre-an-vitaminpiller
Seems like it’s been more or less confirmed by other studies as well.
Eat some fruit and a carrot!
It’s a strategy. No products. No quadrants. Just a more reasonable way of looking at business IT and enterprise development.
It happens to mesh well with my experiences and it’s sometimes nice to be able to whack “Gartner” about in certain settings - especially when someone’s trying to get traction for a magic quadrant product! :)
And to be fair - this is a thread about SAP and ERP…
In a postmodern ERP there is no ERP.
It’s a strategy where you accept that different domains and companies know their business and processes best and you integrate best of breed systems & services with homegrown solutions.
You trade the convenience of letting SAP or Salesforce own your processes against flexibility and actual agility.
The cost is competence - you’ll need developers working in stable, dedicated domain teams, even within the administrative/cost-center areas such as HR & Finance. But there is a massive potential in this approach. It forces ownership of processes and allows for rapid changes of digitized processes, integrations and technology.
I must stress stability of the teams: agility comes from building domain knowledge and continually working on contracts between organizational units over time. This is the complete opposite to classic project management.
SAP caters to non-tech savvy businesses people striving for control, which is something they think is achieved through “one system”. I personally call it the “one system trap”.
In the end what matters is data, and that data do not have to reside in one database. In fact, it’s better for everyone if it doesn’t - this is what ELT is for.
[0] https://www.gartner.com/en/information-technology/glossary/p...
Mind you - to "them", these "dreaded MBAs", the development organization is a problem, often regarded as cost, and development is done by... developers. Sometimes the developers is the actual problem and they have gradually sunk the software in to a unmaintainable swamp of crappy code and debt - but this is a competency and hiring problem. It will not be solved by any framework or project manager. But you need the competency in your leadership to understand what's what and this is missing from pretty much any large org I've set foot in. The high functioning teams is these settings are more a stoke of luck, and they often have to utilize guerrilla tactics to keep delivering value.
I've seen my fair share of global CIO's talking us through cloud and blockchain, never have to actually deliver and move on to the next company or fancy role.
I've seen CIO/CTO not trusting developers and believing no-code and citizen development to be the end all. Guess what - more unmaintainable crazy stuff
I've seen large organizations falling in to the "one system" trap on all levels, even trickling down to the software teams - a dedicated 8 person jira team for the whole org! What could possibly go wrong.
I've also witnessed amazing autonomous development teams that move at amazing speed with quality. In these settings you have management that understands the process of supporting a business with valuable code.
Most of the time IMO it's the business themselves that cause a lot of the problems facing developers by not understanding that it's they who own the processes getting digitized.
They buy software from vendors, staff up a project team to integrate, fire and forget. This "fire and forget" project mentality is what accumulates in a shitty org, and shitty orgs start from the top.
If you haven't read "Turn the ship around" it embodies all of this. This condensed video is really worth a look: