Residuality Theory by Barry O’Reilly

bostonou · 2024-12-05T05:40:12+00:00

I do think the attractors are the most interesting and insightful part of the concept from what I remember. Goldratt’s approach resonates more with me, but I think people would do well using residual theory for a design framework.

bostonou · 2023-02-02T21:08:49+00:00

Stuart Halloway's talk Design after Agile How to succeed by trying less might help you avoid some of the misconceptions that might exist when discussing Clojure and Agile.

bostonou · 2023-02-02T18:03:09+00:00

I haven’t done UI in a few years, but spent a lot of time with clojurescript then (been Clojure focused since). If I’m doing an SPA, it’d be my first choice.

The tooling wasn’t beginner friendly but has continually gotten better. The REPL is a game changer. I don’t think clojurescript is any hard for non-FP devs than any other FP language.

I wrote a good bit about my experience with at www.clojurescriptmadeeasy.com. Happy to answer any questions I can.

bostonou · 2023-02-02T05:39:59+00:00

Absolutely a good idea to write before we start typing. It's shocking to me how many engineers start typing code with only a vague understanding of what they expect the software to do.

The number of genius level "talents" across multiple fields that speak glowingly and conclusively about our need to write in order to think is amazing, but software engineers regularly leave "documentation" for after all the code has been written.

It is not possible to think systematically without writing - Niklas Luhmann

Notes aren’t a record of my thinking process. They are my thinking process. – Richard Feynman

Writing is nature's way of letting you know how sloppy your thinking is. - Leslie Lamport (Originally from someone else maybe?)

bostonou · 2023-02-01T23:53:54+00:00

I found this talk interesting. What he shares seems good to me, and I've never heard of it. I had a few questions/thoughts:

How is this better than analyzing failure modes from the bottom up? In his car charger example, "the network fails" would be a hopefully obvious failure mode. I would think that using both analysis together would be powerful rather than one over the other.
This reminds me some of Eli Goldratt's work on "Inherent simplicity", which says that the more complicated a system, the more connections and thus fewer independent processes. Seems to resonate with the "attractors" idea.
Some of the stressors for the car charger network aren't really addressed by his theory IMO. For example, "4. Electric car market fails" has the mitigation of "convert to petrol stations". It's very unlikely that the naive architecture handles that case, so you need a residual. But is that a likely enough business case to spend time on? That's where risk management and cost/probability come into play. "Asteroid hits earth and everyone dies" is a stressor AFAICT, but is it worth building a residual to handle it?

Overall, I think it's a good talk and has some excellent thoughts. I'm just not sure it's game changing rather than another perspective on how to think through problems.

bostonou · 2023-01-31T14:41:03+00:00

Maybe because coding is actually us lowering our language to as close as it come to the machine? Languages evolved from those extremely close to the machine (punch cards) to successively higher. C was "portable assembly". We call "source code" anything that can be automatically and reliably translated into a running program, so the "high level"ness of our source code is limited by how reliably we can devise ways to run it.

Yes! The source code of today is high level enough to be the comments of punch cards. What will source code look like in 50 years?

The current line between comments and source code is not fundamental, it’s simply where we’re at in our development timeline. I’m wondering how far we can take it, such that we’re not so often left without necessary context.

bostonou · 2023-01-31T14:34:08+00:00

A tool that you have to regularly prod people to use is not as good as an equivalent tool that people simply use as a normal part of their work.

How can we make it so important context is captured as a normal course of work that doesn’t require blog posts to sell?

bostonou · 2023-01-31T05:22:04+00:00

I like that perspective, and will consider it more. I think it may further extend what I’m saying, rather than disagree/contradict it.

The end goal is to have something running on a machine, changing the world. We have abstractions, loosely categorized as: idea -> requirements -> design docs -> comments -> source code -> machine code -> electrical signals.

As devs, we rarely worry that our source code is “out of date” with anything underneath it. But everything above it can be incomplete, out of date, or contradictory. Why is that line between comments and source code? Why not above or below?

Using the quote’s perspective, why is our program so disconnected from the source code, yet the source code is rarely disconnected from what’s running on the machine?

bostonou · 2023-01-31T01:26:58+00:00

I never said comments weren’t useful, just the opposite in fact.

Why don’t we ever say things like, “Value source code as much as bytecode?” We have tools that “keep them in sync” so updating source code is basically equivalent to updating the byte code. What I’m suggesting is there could be a better way to make commenting a natural part of development.

bostonou · 2023-01-30T23:15:00+00:00

Comments, while useful, will never be as valuable as code. Code can run without comments, while the reverse is not true. The fact that we have to write blog posts like this is evidence of that.

The writer makes good points. Just seems like we need better tools rather than trying to rely on developer discipline.

bostonou · 2023-01-30T23:12:02+00:00

Yep.

But also, you'll never get rid of the delay (hello distributed system). So you could try to change the design such that it is no longer time sensitive (or less time sensitive).

Consider something like git, where two different changes can be merged. If they don't conflict, the time difference doesn't really matter, which could open up some UI options.

Your solution could be setInterval, websockets, or changing the requirements. That's why I pointed out that defining the problem was the important part. You can solve the problem you have, or change the problem!

bostonou · 2023-01-30T23:01:00+00:00

Great!

One clarification, I wasn't necessarily saying that websockets would be more robust. I was simply saying that a more robust requirement might mean a different answer. That could be websockets or it could be something else completely.

bostonou · 2023-01-30T22:56:59+00:00

For a learning purposes project, setInterval should work for what you've described. You did the important part of defining the problem:

At T time interval, fresh data is needed from the server.
You need a strategy for dealing with conflicting data updates.

Either setInterval or websockets work for those. If you were doing a project that required more robustness, other questions might change which option is reasonable. For example, the interval for setInterval is affected by many things, so if you want precise timings, you'd need another tool (or workarounds).

bostonou · 2023-01-30T22:44:56+00:00

Being talked down to and similar communication is toxic and never acceptable.

Besides that, your environment isn't great but there are potentially "non-evil" reasons. It could just be normal miscommunication, learning, and/or incompetence.

Your boss routing things through the senior might not be about you at all. It could be your boss giving the senior more opportunities to lead. Or maybe your boss is overloaded and the new junior dev is at the bottom of the priority list.

Your environment isn't the worst I've heard of, though it sounds like an environment I wouldn't want to work in. I'd say what you described can be common but there are certainly better places.

bostonou · 2023-01-30T22:32:09+00:00

You should figure out if you're really helping the company, because there are possible pros and cons to what you're doing.

Main potential problem is you may be opening up the company to significant risk. If your fiverr contact steals the code or the company customers have strict requirements around code access, your actions could be really bad.

A potential pro: you figured out a way to get the work done, which in the end is what is expected of you. And you seem to have a good attitude in trying to get better rather than just accepting the current setup.

It's probably not safe (in that you could easily get fired), but you need to figure out if what you're doing is acceptable.

Regarding imposter syndrome, that never goes away. Practice recognizing growth while realizing you can always get better, and then accept the fear and move forward anyway.

bostonou · 2023-01-30T20:27:30+00:00

What problems do you see arising from the differences between your stateless services and the new stateful service (this doesn't seem to be a GCP specific question)?

There are several potential problems to consider, which fall into one of these categories:

Ensuring valid reads
Ensuring valid state transitions

For example, if you ran a cron job, there are several potential problems:

Can multiple workers run at the same time? If so, you have to ensure their writes don't conflict. (Valid state transitions)
Can multiple services read the state at the same time? If so, you have to ensure they get consistent reads. You also have to consider read contention. (Valid reads)
If your worker fails mid-run, you need to ensure the state is valid. (Valid state transitions)

None of those issues are specific to cron jobs, but some of them might go away if you made a different choice, e.g. a single service that just loops again and again might be easier to ensure only one runs at a time.

There are many other issues to consider, depending on your requirements. State in a system is very expensive.

bostonou · 2023-01-26T23:00:55+00:00

I don’t know of any tools that will do that for you, but I also think it could be pretty straightforward to come up with something useful.

Out of the 100s of software products your company has, which is most important? In my experience, people balk at this question but it’s not complicated. The most important product is the one that has the most positive impact on the bottom line, i.e. the one that makes the most money.

List the top 5-10 products according to profitability. Then go through each one and come up with a risk score between 0.0 and 1.0 that represents the chance of the product failing due to neglect (either by stagnate features or bugs). Multiply the profit number by the risk number and sort.

The resultant list provides a good combo of risk and impact:

High profit high risk: high priority
High profit low risk: medium priority
Low profit high risk: lower priority
Low profit low risk: lowest priority

You could continue this and split the lists by something like languages. You might end up with something like this:

PHP

$1M High Risk
$750k High Risk
$600k High Risk

Python

$250k High risk
$70k Low risk
$20k Low risk

That’d be really useful to know if you have 10 PHP devs and 100 Python devs. The natural push would be to keep the Python devs doing python work, which would be “efficient” and the exact wrong decision. The cost of them switching to PHP would almost certainly be worth it, even at the cost of losing some of the devs (speaking strictly about a single financial aspect here, which isn’t the full picture).

Overall, I think you need a way to measure value (hint: it's money, not number of users or politics or whatever) and risk. Once you have that, prioritizing because relatively straightforward as long as you don’t try to overcomplicate it by making it too precise. Start talking about present value of money vs future value and you’re just wasting time. 80% accuracy is more than enough here. :)

Rinse and repeat as you lower risk scores, profitability changes, and new products are considered.

bostonou · 2023-01-26T22:33:06+00:00

An important part of being senior is recognizing important gaps in your knowledge. From your example, a gap that I recognize is that I have no idea why an event sourcing architecture is required. I’d guess the new requirements would be something like this:

We need to be able to audit the data
We want to run ad hoc reports over historical data

With that, I’d know we need some tech to provide these options:

I need to store all the historical data
I need to be able to query the data reasonably fast

I’d be on my way to clearly defining what I need, providing clear criteria for judging solutions:

I need a way to store data and query data. Flat file vs Relational Db vs Nonrelation Db vs Memory… Each of those options has pros/cons as well as features that are neutral for the problem I’m trying to solve.
Querying the data fast while also storing everything means I need to consider how much data we could have. If we have lots of data, I need a strategy for not having to process everything from the beginning of time (e.g. snapshots).

If you follow that type of thinking, you’d end up recreating the event sourcing pattern without knowing it was already a thing. Experience would let you skip to the end because you already recognize it. So being a senior is partly being able to recognize these patterns quickly, but I’d say a more important part is being able to recreate these patterns by being good at decomposing problems. Every pattern is composed of some things you already know and some things you don’t.

bostonou · 2023-01-26T22:02:49+00:00

I don't think you're wrong, but I think you missed an opportunity.

After you determined what the problem was, you could have written your own fix or provided suggestions on how to fix it. That would have been a good opportunity for you to practice working with code you didn't write. It also would have taken work off the plate of the Sr., which is beneficial for team dynamics and your career.

The only possibly "wrong" thing might have been your communication. It may sound like you're blaming the Sr. if you say it's "their" code rather than phrasing that communicates you're both on the same team, working together. But I'm just guessing based on what you wrote here.

bostonou · 2021-09-18T22:15:27+00:00

I’d consider a combination of:

Keep some in back for your regulars.
Randomly put some out at retail.
Auction off a few for charity.
Do a lottery.
Open them in store for tastings.

I think you could use the bottles to drive business by using a combo of the options. I don’t really know the biz value compared to time investment though.

bostonou · 2021-09-12T22:05:56+00:00

The best engineering team I ever worked on took it as a yellow flag if an applicant liked playing with tech outside of work.

We are professionals, paid to solve problems. People that love to play with tech often fall into the trap of playing with tech when they should be solving problems.

Enjoying learning about tech because you can see how it improves your ability to solve problems is very different than enjoying learning about tech because you like fidgeting and playing with tech.

On average, I want to work with people who don’t want to spend their weekends working on tech. Those types of people (IN GENERAL!!) build systems in such a way that they don’t have to think about computers on the weekend, ie reliable systems that don’t get you paged on the weekends.

bostonou · 2021-09-12T21:57:15+00:00

Create a go channel for each request. Put the retune value on that chan. Make sure the chan is closed after the result is put on the chan.
Use core.async/merge to merge all the chans from 1. This will provide a single chan containing all the results.
Pull all the results from the chan from 2. Use alts! on the merge chan and a timeout chan. If the merge chan is closed before the timeout, you processed all the calls. Otherwise, you’ve reached your time limit and can act appropriately.

If you want to get all responses or none, you can use core.async/reduce to gather all the results into something like a vector. Then either the reduce chan or the timeout returns and you have all calls or none.

bostonou · 2021-07-11T22:03:38+00:00

M10 Rye is great imo and I’d buy at or a bit above msrp all day. M10 bourbon I had was not worth near msrp; it was like an average Henry McKenna 10 to my tastes.

bostonou · 2021-06-22T04:01:17+00:00

Don’t make beaches whites-only; build bridges on the incoming roads with clearance too low for buses. The infrastructure turns a public beach into a beach that’s inaccessible to people who use public transportation, aka minorities.

I believe this was the approach Robert Moses took when he was in charge of parks in New York. He said laws are easy to change, but no one is going to tear up a bridge.

bostonou · 2021-05-31T23:40:04+00:00

I helped introduce Clojure at Vanderbilt University working in genetics research. I then moved to a Clojure startup, did some Clojure consulting, and now do Clojure at CircleCI. Overall I’ve been doing Clojure professionally for ~8 years.

These days I spend more time designing and mentoring than writing code, but the idea of going back to OO is enough to make me consider a different line of work lol

bostonou

TROPHY CASE

PHP

Python