About
Services
Courses by Allen
-
Software Architecture: Domain-Driven Design1h 19m
Software Architecture: Domain-Driven Design
By: Allen Holub
Articles by Allen
Activity
32K followers
-
Allen Holub shared thisAn interesting choice. The devs have been spending too much time watching historical romances or GoT. I wonder how many people in the nobility have been calling tech support, demanding proper titles in the name-entry field, and why have they left out Dame and skipped straight to viscounts? Putting aside humor for a moment, I once worked with a team that had been told their code had to support the ANSI X12 standard for names and honorifics (they have a standard for everything!). The standard covers everything from Mr. and Ms. to nobility to Daenerys, Mother of Dragons, Breaker of Chains. The team had spent weeks on this garbage. I finally marched them over to a meeting and forced them to drag the PO out and demand an explanation. They had none, so we all marched over to the (internal customer), who said "Mr." and "Ms." is fine. Probably saved the company $100K. Don't write code that nobody wants, and question everything you see in a spec.
-
Allen Holub reposted thisAllen Holub reposted thisIt's weird to hear all the people talking about the huge productivity boost and new innovations from AI when we're not seeing them. These things are useful, and I use them, but I'm not 10x the programmer I was, or even 2x. I spend a bit less time looking things up, though, and I can get an example of how to do some things when I want. The huge transformational power of AI revolutionising apps and driving innovation, though? I don't think we see anything like that. So, either the tech needs to step up (A LOT) or the hype needs to die down (A LOT). It's upsetting the extent to which marketing materials tout something that's so unproven.
-
Allen Holub shared thisThe attached screen grab should make everybody who programs AI systems pay attention. As programmers, we should never forget that so-called AI is just numbers and probabilities. Because of that, LLM-based systems are inherently insecure, not from exploiting bugs—the way standard hacks work—but because the underlying mathematics is intrinsically insecure. LLMs work using a compression/expansion mechanism. The LLM converts your input to numbers (tokens), picks another number (token) based on probabilities and prior tokens, then converts that second number back to text. It does not know what the input text means, and it does not require that the input text correctly express any natural language (that's why spelling errors are accepted in a prompt). The key thing is that the set of tokens, though huge, is vastly smaller than the set of potential inputs. Consequently, disparate inputs, not all of which are meaningful in any human language, can generate the same number (and same result), and by the same token (so to speak 😄), minor variations in the input can result in different numbers, and yield different and undesirable results. That screen grab is from an AI movie rating system. Note how trivial misspellings in the prompt change the rating in unintended (to the user) ways. In other words, minor variations in the prompt can radically change the system's behavior in undesirable ways. This exploit works with all LLM-based systems, and YOU CANNOT DEFEND AGAINST IT. It's inherent in the mathematics that define how an LLM works. No matter how many inputs you exclude through examination, there is an effectively infinite set of inputs you did not exclude that can do the same damage. This problem may not be the end of the world if you're rating movies, but if you're creating AI agents that touch the real world, it's a huge deal. The lesson is, outside of a chatbot, never never never never use a prompt that you yourself did not write and carefully vet. Every external entity (not just "users," but also bots) can hack your system through the prompt, and there is literally no defense for that other than controlling the prompt. Of course, many "agentic" systems rely on unvetted prompts. These systems are inherently insecure (and dangerous, if we are talking unintended consequences) and can never be made secure. It's just math. Consider yourself warned. (P.S. I should add that recent LLMs are not as susceptible to spelling errors as that example, but no probability-based system is secure, no matter how contemporary.)
-
Allen Holub posted thisWe all work under constraints like time or budget, even when working incrementally. You do not solve that problem with a plan, however, particularly an inflexible one. (You do need a product strategy, but that's a higher-level thing. Plans are tactical, not strategic.) So, how do you handle constraints? First, budget the annual cost of the team (salary * load). You pay for the team even if they sit around and play canasta all day, so budget for that reality. Now assign the team to the product or product area (no projects) that provides the most customer and business value. This is a basic Lean concept: bring resources and people to the constraint—the place with the most demand. That's a moving target, so discover what to do through feedback from small incremental releases, and adapt continuously as needed. There is _always_ more work than budget (or time), no matter how you work. Solve that by continuously assessing what to do through the lens of user/customer (and therefore, business) value. Always do the most valuable thing next. When the budget or time runs out, you will have built the best thing you could have built within the constraints at hand. When time and money are fixed, scope must vary. Fixing all three is a death march.
-
Allen Holub posted thisTo me, the whole idea of managing scope is antiquated and not particularly useful. It assumes an inflexible up-front plan from which it's bad to deviate. It assumes a schedule based on that up-front plan. However, scope defined upfront does not work, and it never has. The notion also assumes project thinking, where you estimate based on that up-front plan. To me, all of this is dysfunctional, at least if you want to build something that somebody wants to buy and not waste a lot of money doing it. It's best to figure out what to do next by doing the current thing (and getting feedback). Talk to your customers to figure out where to start. Pick the smallest core of the core of the core idea and build that. Get feedback. Use that feedback to decide what to do next. Release immediately to get revenue sooner. There are no projects. There is no "scope" to creep. There's just a continuous stream of added value. Stop when there's nothing valuable to add.
-
Allen Holub posted thisI often see a website for a company that ought to know better using URLs that look like phishing attempts. Microsoft, for example, sometimes shuttles you to "microsoftonlione․com" (with a side trip to something called live․com) to log in. My (small, local) bank shunts me over to a completely unrelated domain that, I assume, is the supplier to whom they farm out their website. Me being me, I called the bank to verify that this wasn't a hack before I trusted it, but who else would do that besides paranoid security people? If you're considering offloading part of your website to a third party that doesn't support you using your own domain, go elsewhere. Not using your actual domain for your entire website is a horrifically bad practice. The primary defense against phishing is checking that the domain matches. Subdomains exist precisely for this purpose. Use them.
-
Allen Holub posted thisI'll admit that I occasionally watch Forged in Fire (a reality show where people make edged weapons under time pressure—don't judge 😄). One of the things I find particularly interesting is how the contestants continually make the same mistakes that brought down contestants in previous shows. They go on the show with not even the basic prep of watching a season or two in advance and following the judges' advice. Every season, they make Canister Damascus (Google it) with white out—something that elicits audible groans from the judges literally every time, and pretty much always leads to disaster. Arrogance is a big part of it, of course. Many of the losers puff themselves up in their intro bios. They think they're great with no objective corroboration of that opinion. I see the same thing going on all the time in software construction—the same tired mistakes made over and over again by arrogant practitioners who can't be bothered to read up on their craft. How many programmers spend time reading code to learn from it? I often see something that makes me think, "We tried that about 10 years ago—didn't work out very well." (Server-side JavaScript comes to mind immediately 😄.) Interestingly, there are other similarities. Blacksmiths are often self-taught and often work alone—there are very few blacksmithing apprenticeships. There are no meetups (we used to call those "guilds"). Programmers are also largely self-taught—a combination of the failure of our educational system (which favors PhDs over industry experience when hiring) and the ageism that infuses the profession. There are simply no experienced people around to help, and if there are, their input is often denigrated as "outdated". It's the blind leading the blind. This systematic removal of experience from the workplace is not cost-effective, but here we are. Experienced programmers DO NOT "cost more" when you factor in the time wasted by not having their expertise in play.
-
Allen Holub posted thisI will never understand how people do not see the tight coupling of security and quality. You can't have the former without the latter. They call it an "exploit" because the hacker is exploiting a bug. You can't just inject after-the-fact "security" into a system because you can't inject quality into a system. Both characteristics infuse the code. The only way to make an insecure system secure is to replace the low-quality code with high-quality code. Band-aids don't work.
-
Allen Holub posted thisLet’s talk about “Move fast and break things.” First of all, Facebook itself changed its motto to “Move fast with stable infrastructure” in 2014. So much for breaking things, at least if you’re a soulless corporate behemoth. Even if you’re a startup, though, breaking things makes no sense at all unless you’re talking about breaking the status quo in a moribund product space. Who has time to fix broken stuff? "Move fast” is more interesting. Fast gets you two essential things: you get revenue sooner, and you get the feedback you need to ensure you’re building something the market actually wants. “Move fast” doesn't mean: get low-quality buggy garbage out the door faster. That slows you down. Every change to buggy code is painful (and time-consuming), particularly when you have no tests because you have “no time to write them.” You have no time not to write them. The best way to move fast is to increase quality and be serious about testing. Also, buggy systems drive customers away. No startup can afford that. Bugs erode trust, and attempts to regain that trust by releasing a slightly less buggy version in a month are doomed. People have long memories. There are constructive ways to move fast, though. The first is to change the way you work. Traditional Lean thinking—e.g., remove waste; work on one thing at a time (reduce WIP to 1)—cuts development time in half or more. Working collaboratively (e.g., mob/ensemble programming) eliminates coordination and integration overhead. Whole-team development—where all the skills needed to get something out the door are available within the team—eliminates dependency delays. The next set of speed improvements comes from not building infrastructure you don’t need. If you have 100 customers, for example, you probably don’t need a database—a flat file with JSON in it will do. You almost certainly don’t need that slick UI (you need a good UX, but you can often get that with a very simple UI). You do not need an architecture or infrastructure that supports 100,000 users until you have 100,000 users. You do need an incremental-friendly architecture--one that can evolve as it scales. Eminently doable, but it’s a learned skill. The most dramatic speed improvements come from not building entire features that nobody wants. Work very small to get code into your customer’s hands as quickly as possible, and then get feedback from them in a continuous conversation. Why build things nobody cares about? I’ve often released a small thing devoid of most of the features and bells and whistles I thought I needed, and the feedback was “this is great!” At that point, I’m done. Those bells and whistles were cruft. Build the thing that alleviates the most pain first, then get feedback. So, I’m not sure about breaking things, but moving fast is always a good idea. You just have to go about doing it sensibly.
-
Allen Holub liked thisAllen Holub liked thisIt's weird to hear all the people talking about the huge productivity boost and new innovations from AI when we're not seeing them. These things are useful, and I use them, but I'm not 10x the programmer I was, or even 2x. I spend a bit less time looking things up, though, and I can get an example of how to do some things when I want. The huge transformational power of AI revolutionising apps and driving innovation, though? I don't think we see anything like that. So, either the tech needs to step up (A LOT) or the hype needs to die down (A LOT). It's upsetting the extent to which marketing materials tout something that's so unproven.
Experience & Education
-
Holub Associates
View Allen’s full experience
See their title, tenure and more.
or
Volunteer Experience
-
"Agile And Lean Software Development" group co-moderator
LinkedIn
- Present 7 years
I actively co-moderate (there are three of us) the largest Agile-and-Lean discussion group on LinkedIn, currently 215K members [https://www.linkedin.com/groups/37631/]. I help people with agility, answering pretty much every question that's posted. Reading my posts will give you a good feeling for my general software-development approach.
Here's the group description: Agile and Lean Software Development LinkedIn Group is the largest online community (over 200K members) of Agile & Lean…I actively co-moderate (there are three of us) the largest Agile-and-Lean discussion group on LinkedIn, currently 215K members [https://www.linkedin.com/groups/37631/]. I help people with agility, answering pretty much every question that's posted. Reading my posts will give you a good feeling for my general software-development approach.
Here's the group description: Agile and Lean Software Development LinkedIn Group is the largest online community (over 200K members) of Agile & Lean practitioners from around the world. An open platform for you to connect and exchange ideas with peers. Enjoy the in-depth discussion on any topics from Agile, Lean, eXtreme Programming, Scrum, Kanban, DSDM, FDD, Crystal, Organizational Transformation, Product Discovery, Agile Adoption, TDD, BDD, Continuous Delivery, Continuous Integration, Lean UX, Exploratory Testing, Code Quality, DevEx, DevOps, Chaos Engineering and more. -
Member, Board of Directors
Berkeley Hillside Club
- 2 years 1 month
The Hillside club is a social club located in Berkeley, CA. We're the steward of a 1910-vintage hall, present regular events for members, and rent the facility to the public. (http://hillsideclub.org)
Publications
-
Picturing Architecture: UML (The Good Bits) and More [video class]
Pluralsight
See publicationPictures are an essential part of both understanding and communicating the structure of software. This is particularly true in an Agile environment. However, tradition pictorial tools (UML, for example) were designed for a big-up-font-design waterfall world, and have largely been abandoned as a consequence. This class is an agile take on pictures of software. It describes how to create and manage stories (and story cards), how to represent messaging systems and systems of classes (both using…
Pictures are an essential part of both understanding and communicating the structure of software. This is particularly true in an Agile environment. However, tradition pictorial tools (UML, for example) were designed for a big-up-font-design waterfall world, and have largely been abandoned as a consequence. This class is an agile take on pictures of software. It describes how to create and manage stories (and story cards), how to represent messaging systems and systems of classes (both using CRC-card walls, an innovation of the authors, and traditional diagrams). The focus is on communicating at a whiteboard, not on creating detailed plans to be implemented by "code monkeys."
-
Design Patterns in the Real World (video)
O'Reilly
See publicationAn in-depth introduction to the "Gang of Four" design patterns based on analyzing realistic programs in terms of the patterns used to implement them.
-
Swift in Depth [video class]
Pluralsight
See publicationAn in-depth introduction to Apple's Swift programming language for programmers who are already familiar with OO concepts. No prior understanding of Apple technology is required, however. One of Pluralsight's top courses.
-
The Swift Compact Reference
Self
See publicationA reference for Swift programmers. Presents the entire language on a stack of 4x6 index cards.
-
Holub on Patterns: Learning Design Patterns by Looking at Code
Apress
Presents the "gang-of-four" design patterns in an unconventional way by deeply analyzing two realistic computer programs (an embedded SQL interpreter and a Game-of-Life implementation) which, between them, make use of all the patterns at least once.
-
Taming Java Threads
Apress
Written before the java.util.concurrent package existed, presents the complete source code for a comprehensive threading library for Java. One of Apress's all-time best sellers.
-
Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming.
McGraw-Hill
An extensive style guide for improving the quality of C/C++ programs.
-
C+C++: Programming With Objects in C and C++
One of the first books to present C++ expressly for existing C programmers.
-
Compiler Design in C
Prentice Hall
An exhaustive engineering approach to compiler design, presents complete theory along with the full source code for variants on the UNIX lex and yacc utilities and a complete C compiler. Introduced a "visible parser" that allowed students to actually watch a LALR(1) parser work as it processed a source-code file. Used as a text at MIT, IIT, CUNY, and Cal Tech (and as a secondary text at U.C. Berkeley).
-
The C Companion
Prentice Hall
Presented all the background material that you need to develop a deep understanding of C without presenting the language itself (e.g. Stack Frames, Binary Arithmetic, Boolean Algebra, etc.).
Recommendations received
44 people have recommended Allen
Join now to viewOther similar profiles
Explore more posts
Explore top content on LinkedIn
Find curated posts and insights for relevant topics all in one place.
View top content