We went through these phases over the years:
Build a JAR or WAR and deploy it to an application container such as Tomcat or WebLogic.
Build the same type of JARs with slight modifications and deploy them to AWS Lambda.
Deploy to Datomic Ions
For worker-type applications, wrapping the JAR with a service supervisor has been enough.
Someone for whom it’s equally easy to shift the building up and put a new foundation down as it is to change the colour of the door. Someone who can easily reach past the layers of wood and insulation to add a new room below.
If you don’t utilize the advantages of software (easy to delete, easy to redo, easy to reuse) when building software, then that’s like treating your helicopter like a car and only flying over roads, and waiting for the cars on the road to move before you move. The helicopter is not a car. It doesn’t have to follow the road. Software is not a house. You can fix the insulation directly.
In software, a near-complete spec could be the program itself.
I think that’s only true for small projects. Facebook find it easier to extend PHP than rewrite their legacy code. Also, how most banks are still stuck on mainframes.
Having a vast cabinet full of blueprints will merely mean before you can change anything, you first have to find and change the blueprint…. a task which is as hard if not harder than changing the code.
Especially as, odds on, the blueprints are out of date since nobody does roundtripping.
Or you can look at the problem differently….
The most precise and concise and readable and understandable representation of software is the code.
Of course, if you start with a crap representation (aka PHP) and find yourself at the bottom of a hole…
What’s the rule about getting out holes you have dug yourself into?
The most precise and concise and readable and understandable representation of software is the code.
That’s like like saying “The most precise and concise and readable and understandable representation of a novel is its text”. It’s precise and complete, but usually not concise. And sadly, it is often the only way to find out how it works. In many projects I would have killed for a 10-line description of the architecture and how it maps to source files.
You need to learn to skim the data structures… and find where the I/O end points are.
Give me those things I will navigate via declaration/reference graph around the system like a monkey swinging on a jungle gym.
OOP gets a fair bit of hate, but I can read the instance variables and immediately say, aha, I have a clue what all this code in this class is doing.
And I will be faster and more accurate than somebody with a cabinet full of blueprints.
Software is a lot worse than a house. The space a house lives in is 3d. The space of a software program is infinite dimensional. You can hide all the bugs in one corner and never notice.
Metaphors are imperfect by definition. I think it’s more constructive to look at the complete analogy and metaphor and see which aspects map nicely and which don’t. Obviously, a programmer intimately familiar with a particular codebase, might indeed be able to change or implement certain features quickly. In other cases, he might not be able to. I think so far the metaphor holds pretty closely. I would distinguish between tasks that require no deep understanding of the architecture (painting a wall, changing a message), and tasks that do (removing a wall – is it a load-bearing wall? – changing a method in the common path – does it break an invariant?).
One difference, I think, is that progress is a lot more visible in construction. In software, you might think you’re almost done with something, but when you have a closer look it might turn out to be impossible to do after all. It’s also a lot harder to mess things up, due to source control. This is a big point why construction requires more planning: If you seriously mess it up, the house might collapse. If you mess up your software, you get crappy software. The difference is that people can live with crappy software (facebook notifications don’t go away on mobile, I can’t disable linkedin job alerts, twitter fails at loading pretty much anything), but they often die when they are in a house that collapses. Indeed, in areas where it matters (cars, aviation, aeronautics, security, large-scale manufactoring), people tend to be a bit more conservative about ‘moving fast’ (and they certainly won’t encourage you to ‘break things’). Indeed, these are areas where formal methods are more often applied than in the rest of the industry.
Another difference between construction and software engineering is that (I think) it is easier to spot obvious mistakes in construction. In software, you might have an obvious mistake, but it might be hidden in a big codebase.
I think the metaphor holds pretty closely when you compare projects of similar size (of course, comparing the ‘size’ of an construction project and a software project is terribly ill-defined). The bigger and the more mission-critical your project, the more you need to plan ahead and ensure safety (which sounds surprisingly much like common sense).
That is true until physics gets in the way. When a system is concurrent, distributed and runs mission-critical logic, the cost of moving/shifting/changing the software of the system may be considerably higher than using formal methods to specify it.
Mr. Lamport mentions an interesting example of a chip designed by Intel for Xbox. It has a bug (that was discovered with formal methods, prior to production). Imagen you have 1 million chips deployed all around the world with a bug. So yeah, software systems are subject to physics too, one way or another.
My bogan uncle, for one. Pretty nice house, too
It’s exactly where the problem is: building houses without blueprints does work, until some point.
Continuing with the house metaphor, until an earthquake happens.
In software assurance, we try to understand recurring risks and mitigate them where it makes sense. Areas with many earthquakes make earthquake-resistant buildings. Taipei 101 was extra interesting in that it had to be both wind and earthquake resistant, which have opposite requirements. Here’s it working during one of the earthquakes.
Similarly, folks in areas with hurricanes build stuff to resist them. There’s even something for flooding now proven in Texas during Hurricane Harvey.
As a software engineer it’s easy to look at the start of this article and say “you’re already making invalid assumptions, stop it”. And as a software engineer in 2019 it’s easy to say “more cryptocurrency hype” and skip it.
But as you go on it’s clear that this guy is doing what physics does so well, which is ignoring what is FEASIBLE to try to figure out what is POSSIBLE. If you bypass the hype, the information theory and thermodynamics bits of the calculation are really pretty cool.
Yes, I like the physics approach to the question. It illustrates an interesting perspective on the “size” of the data that is moved around when we use Bitcoin or even just encryption at all.
I have used the sun-energy explanation before to explain how much effort you would have to invest to break finance-related encryption. But after reading this article, I confess my numbers were way off.
I mean, the big error bar in there is “what if the mathematics becomes better and we come up with techniques to break these hashes more easily”. But it’s still useful, though the author doesn’t consider that… The physics strongly suggests that better math is the only way you are ever going to break a 256-bit hash.
Squats + finish up adding multi-country, multi-currency support to our Django-based e-invoicing dashboard.
I believe the author should use Clojure as an example of boring technology.
I believe for you Clojure is boring. For me to introduce it, would not be - it is very shiny. I do believe the author addresses this, it isn’t necessarily about the specific technologies but how and why we choose them.
He does address it, but it is a bad example that takes away power from the author’s point of view. I’m pretty sure there are a lot of “Clojure maximalists” out there who would think the same. Long old boring Clojure, short new shiny things.
I don’t seem to grasp what is the DDD critique from the article. It wanders from partially describing DDD to talking about MVC patterns. I suspect it confuses software design methodologies with software implementation methodologies.
Software design methodologies are interesting as a whole, and a critique of DDD is curiously interesting but unfortunately this looks simply like click bait.
It’s a good criticism: both yours and his.
The way I looked at it was like this: so much of DDD is about how the software looks, what goes where. (Yes, there’s event storming and few other methodology tricks, but the real thrust of it is program control by types). This article is about process, how do you go about incrementally developing a large system over time?
What this author groks about software development – which oddly enough may be illustrated by his essay itself – is that DDD is nice and pure. Real-word development is messy with a bunch of stuff going on all over the place.
There’s a lot of tension between the two theses for reasons I won’t go into here. I think the key thing to ask the DDD folks is “How does this incrementally grow over time?” and the key thing to ask authors like this one is “But what’s the best way to organize everything?”
I will head off to the beach and read Domain Model Made Functional by Scott Wlaschin.
This is awesome
Face recognition web API at a bank. Written in Clojure + Pedestal, using libraries provided by FacePhi. It is on Github if anyone wants to take a look.
The bank put a SOAP wrapper around it so it could be added to their “omnichannel enterprise service bus”. It is used by their apps to do face authentication.
Squats for sure!
My work area. Just a plain MacOS desktop, nothing fancy. I’m waiting to see what jcs posts :-)
The link doesn’t seem to work
Thanks, I guess something expired with the Google Photos share link.
Tell me about the pig, inquiring minds must know.
I used to have two pet pigs. Unsurprisingly, over the years this has resulted in quite a few pig-themed gifts. Xiaozhu was the first, I think, a crudely-carved little jade pig we picked up in a market.
I always wanted pet pigs, but my wife shot that down. Says “They never stay that small”.
Your wife is correct! Don’t get pigs unless you’re ok with looking after a full-grown one, as even the smaller breeds are still medium/large dog size :-)
My brothers had a pot-belly pig as a pet. They said they act pretty much like dogs if you have them in the house. Dogs with some behaviors specific to pigs that anyone can find online. Back to dog analogy, theirs would great them at the door, like being petted, and jump on their laps when they sat on the couch. Loved playing outside with them. Also liked to flip the children’s pool over its head to run around with it for some reason. It sounded like a trip.
Curious what yours was like since I don’t run into that many people with domesticated pigs.
They are rather like dogs, yes. Ours were only indoors when they were very young, and by the time they were a year old they were living outdoors in the yard with their own pen. They loved basking in the sun, would snooze slumped against each other and would come running whenever they thought there was a belly rub in it for them.
When they were little sometimes they would argue/fight and we discovered the best solution was to throw a blanket over them (it calmed them immediately). A few times this would happen in the middle of the night, and we grabbed one each and put them under the bedcovers by our feet, where they immediately calmed down and went to sleep. Bit odd waking up and wondering for a moment why you can feel a piglet against your feet.
I need to login with a google account?
Sorry about that, I used the Google Photos sharing thing and didn’t realise it wasn’t public (my quick test in an incognito window this morning worked fine, but something has apparently expired somewhere in the meantime). Should work now.
That giant clothespin is awesome
I like it too :-) I bought it in a charity shop many years ago for pennies, and I’ve used it to collect scrap paper and receipts on my desks ever since.
I bought that same keyboard but for the life of me I can’t stand it. I used it for a couple days and had to go back to my unicomp. Just really wasn’t comfortable for me.
It’s worked out completely the opposite for me: I love the laptop-style layout.
It’s like a better Happy Hacking Keyboard. Just wished the Race had a similar bezel to the HHKB.
Please find my answers below:
What does your diet mainly consist of?
On weekdays, I eat a lot of fats (avocado, almonds, eggs, milk, tuna, meat), proteins, fruits and vegetables. I try to keep processed carbs intake down to the minimum. I avoid bread. I drink coffee every day.
A typical lunch would consist of two large boiled eggs, one avocado, one apple and a bunch of almonds. Dinner would be some kind of meat and vegetables.
On weekends I’m more flexible and eat anything (fast food, pizza, chocolates, beer). You know, some kind of cheat meal.
I have been doing intermittent fasting for 2 years so I skip breakfast and start eating at lunch.
Do you normally plan meals ahead or pickup food from places often?
We (wife and kids) plan meals ahead on Sunday and prepare them every day. This helps us control spending and diet on weekdays.
Has working out or being active pushed you towards a certain type of diet?
Definitely. I have been training jiujitsu for 10 years and tried a lot of diets. A balanced diet + fasting is the diet I feel more confortable with these days at 36 years old.
My takeaway is that eating clean and fasting allows me to enjoy workouts and have energy to work throughout the day.
Brazilian Jiujitsu, the human chess