Business software, not Google or Apples size problems, the forgotten middle.
London
Joined September 2012
- Tweets727
- Following307
- Followers56
- Likes1.1K
Chris Austin retweeted
The market for software migration from legacy systems has been limited to $30B a year or so because migration is very expensive and maintenance is easier. Talking to older firms, there is a real backlog of scoped cheaper migration projects being unlocked by AI surprisingly fast
Chris Austin retweeted
Much of the world is based on the assumption that the future is like the past and an original meaning of “singularity” was a point where that relationship breaks. I don’t know if there will be one big Singularity, but a million little singularities across fields seems inevitable.
Chris Austin retweeted
Wieslaw is doing crazy stuffs with AI, it's not slop, it's... punk? 😁
34KB executable, 1.2 MB memory usage, native executable built fully on the web. VB6 Studio Web — a browser-native classic Visual Basic IDE. Build on the web, download single executable. wieslawsoltes.github.io/VB6/
We talk endlessly about modularity in application code, then connect to a database where everything can depend on everything else. Why does modularity stop at the database?
businesssoftwareishard.com/e…
A chance encounter leads to an unexpected conversation about software, its history, and the questions that have been troubling us for decades.
What if some of the answers we've been looking for were there all along?
My new book, The Parnas Suite.
leanpub.com/theparnassuite
Why does it only fail in production?
Because production may be the first place where the (concurrent) program we wrote actually runs concurrently.
businesssoftwareishard.com/e…
POSTCARD FROM 1988
Publishing a library is awkward.
Clients need stability. You may want to extend it.
That’s the problem behind “open for extension, closed for modification”.
Not every class needs extension points.
bertrandmeyer.com/wp-content…
POSTCARD FROM 2001
Heard "customer collaboration over contract negotiation" means contracts don't matter.
Not quite.
The point was to solve the problem together rather than spend the project arguing about scope and change requests.
agilemanifesto.org/
POSTCARD FROM 2001
Heard "responding to change over following a plan" means planning is pointless.
Not quite.
Make a plan.
Just don't pretend a plan made before you started can survive everything you learn while building.
agilemanifesto.org/
POSTCARD FROM 2001
Heard "working software over comprehensive documentation" means documentation is bad.
Not quite.
We were reacting to heavyweight, documentation-driven processes.
Documentation still has value.
agilemanifesto.org/history.h…
At one point, we had effectively 100% automated test coverage.
It sounded reassuring. But a product owner asked a much better question:
“Yeah, but does it work?”
businesssoftwareishard.com/e…
POSTCARD FROM 1999
One example? Solve it.
A second? Interesting.
A third? Now you may know what they have in common.
Then perhaps design the abstraction.
Evidence first. Abstraction second.
en.wikipedia.org/wiki/Rule_o…
POSTCARD FROM THE 1990s
Heard you might need another database one day.
So you’re paying for that flexibility now.
YAGNI is really about investment:
don’t take on certain complexity today for uncertain benefit tomorrow.
From the 1990s.
martinfowler.com/bliki/Yagni…
POSTCARD FROM 1999
Heard you've been deleting duplicated code.
Careful.
DRY isn't about code duplication.
Repeated business knowledge is the smell.
Maybe your module boundaries are wrong.
From 1999.
media.pragprog.com/titles/tp…
We draw deployments, data models and modules when we’re trying to understand software.
But one of the most important structures in business software is often left implicit: the transaction.
businesssoftwareishard.com/e…
POSTCARD FROM 1996
Heard you're inverting everything.
Interfaces everywhere. Injected everything. Can't see how it fits.
Not the idea.
Keep business logic independent of technical details that should vary.
From 1996.
cs.utexas.edu/~downing/paper…
POSTCARD FROM 1994
Programming to interfaces, not implementations.
Heard you've taken "interface" to mean "Java interface for every class".
Not quite.
Depend on what a component exposes, not how it works inside.
From 1994.
en.wikipedia.org/wiki/Design…
POSTCARD FROM 1975
Sorry to hear your project is late.
I hear you're adding people. And another team.
We found adding people to a late project made it later.
Something about communication and coordination.
From 1975.
en.wikipedia.org/wiki/The_My…