HN user

Throw10987

74 karma
Posts0
Comments31
View on HN
No posts found.

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.

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.

Animated Knots 3 years ago

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.

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.

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.

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.

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.

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.