That seems sane, is there a cohort of engineers pushing for trunk based development?
HN user
Throw10987
I think the point is that the Access, Lotus Notes tooling was in largish corporations somewhat ubiquitous.
The experience of this tooling was make a change and it was in production. It was incredibly simple and productive to work with given the needs of the time.
There was also plenty of opportunities to make a mess, but I don't think that has really changed.
Learning was not difficult, you just had to be prepared to spend time and some money on books and courses.
It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time.
Believe me it is not laughing in a good way, it is more a nervous laughter with a permanent sinking feeling in the stomach kind of way.
The collective 'we' developed nations have our own set of problems, but broadly speaking from time to time self correct away from polarisation to hopefully enough of a degree.
A unique kind of leadership needs to be allowed to grow in America to stear a less polarised course.
In my part of the world that would be inner sheep.
Not 100% sure of the rationale in this case. I imagine it might have to do with everyone who runs an instance needs to maintain an additional storage system along with all the associated costs, which is not just storage alone.
Databases store stuff really well. If get to the level of needing to configure storage for different tiers of access they can do that, it just takes a bit of work. Of course if your blob data is stored in tables that have OLTP data in them, then you have a bit of work to do to separate it out.
This is speaking from recent experience of having to manage random blobs of sensitive data in s3 buckets that engineers have created rather than bothering to put in the main application data store.
Robocopy may be an approximate equivalent for rsync. https://learn.microsoft.com/en-us/windows-server/administrat...
I am chartering a yacht in two weeks and have been busy re-learning how to tie a core set of knots. This is easily the best resource that I have been using with the rest of the crew(aka family)!
Sound advice - currently going down the path of try to make the role better. It will however be a long journey, so need to work out whether I am sufficiently committed to the path. Also need to work out what the ejection criteria are, regardless of my commitment or not.
I am the most senior engineering IC by position and years of experience at my current company in a 100+ person engineering group. The only problems I deal with are non technical and organisational in nature, despite on paper being expected to code 30 percent of the time.
And loving it ;)
I find myself coming back to Data and Reality on a periodic basis to remind me that the model is just the model.
This by the same team who brought you the DORA metrics and the SPACE framework. I suspect it is really a vehicle to sell books and consulting, despite the article largely making sense.
Maybe it is atonement of some sort.
Leadership, Process and Discipline
Role is "disestablished"
I have to add “If you know the way broadly you will see it in all things” from Musashi which conveys a similar sentiment.
I think the second amendment was probably intentionally not mentioned.
I have seen teams spending most of their time on working on the highest priority (by a single measure) and not spending any time on overall delivery efficiency.
So having a balanced prioritisation approach would seem to be pretty important.
I think if you rephrase it that they "dragged the whole company out of the particular IT hell that is associated with banks owning, running and procuring infrastructure" it probably makes more sense.
No, to the point that there is this website - https://safedelusion.com/
I thought I was the only one old enough to remember that we have been here before.
Back in the day I even had an email thread with Ryan Dancy about making software tooling based on the OGL, which was pretty non-committal and discouraged me from proceeding with any efforts.
My company is and ayecarumber, it resonates.
There are a multitude of different ways to bridge from mainframe (IBM Websphere MQ/Host integration server) systems or to make file based systems look mostly online (small, frequent batch files). So technically it is possible and done pretty reliablly for banks and the like.
Extending use cases to cover behaviours that were not covered by the original software is where things get exciting. You will end up with a hodge podge of systems & processes that try to implement multi-step work flows and deal with failures through manual or equally complex automated methods to compensate.
Generally most industries are pretty terrible at evolving the solutions they have or completely replacing them. So you will see a multi-generational set of systems that are in place to provide an acceptably current set of behaviours.
This situation can arise due to varying commercial pressures, however Developer and Engineer's inability to communicate what the system currently does and what is easy and hard to change in no small way contributes to following paths that result in poor system outcomes over the lifetimeof systems.
Agree, was super excited when I saw reference to the German tank problem as that is immediately what I thought of in the first post.
This used to be the way. Now it takes a whole team to put a textbox on a Web app.
I feel this could be dangerous advice to follow.
Banks are tech companies, the business leadership just don't know it.
Case in point, Sydney Au is starting water restrictions despite record rainfall due to quality of water in catchments.. Not that far from boiling water.
https://www.nsw.gov.au/environment-land-and-water/water-rest...
Veterans Affairs is also a big Chunk of change that also goes on in perpetuity. 412k employees and 10+ million on benefits
Depending on how you count, defense industry could be 3.5 mil employees.
https://siteselection.com/issues/2012/sep/sas-military-econo....
War is a racket - Smedley Butler Major General US Marine Corps https://en.m.wikipedia.org/wiki/War_Is_a_Racket#:~:text=War%....
I think there is general acceptance that the implementation details in Eric Evans book could almost be completly skipped. The concepts of domain boundaries and the ubiquitous language are the useful if seemingly obvious bits.