Lázaro Fernández

Senior Software Developer en Sequel | Me gusta el fútbol, y escribir de él en mis ratos libres | Creador de @FutbolRH y @yubukit_com

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

One hallmark of a lousy app is that it's chock full of features. A good app does one critical and necessary thing well. A pile of features typically does nothing but add clutter and make the app harder to use.

You cannot compete by adding features. You compete by implementing the core capability better than your competitors do.

A plethora of features typically happens for several reasons: (1) The creator of the app doesn't actually know what that single key capability is, so they implement lots of features hoping that one will stick, or (2) The app is unsuccessful, so the creator keeps tacking on more and more fluff in the hopes of stumbling on something people will like, or (3) the creator can't make up their mind about anything (usually because they don't know what's "right"), so every decision they deffer becomes an option or another feature.

None of these strategies solve the main problem, however: no communication. Nobody's taken the time to figure out what customers need because the only way to do that is to talk to customers and potential customers. Too many founders skip that step entirely. Instead, they guess, and the ("I have a Great! Idea!) guesses are usually wrong. Successful apps start out with conversations with (potential) customers. That's the only way to discover what they actually need.

I suppose there's a fourth possibility, which I think of as Microsoft Word syndrome. Some moron in Product has decided that people won't upgrade unless there are more and more features in every release, so the clutter accumulates with no real added capabilities. They'll also make specious UI changes while they're at it, making the app even harder to use. I'd be happy to pay for upgrades that fix longstanding bugs and make hard things easier to do, but that never seems to occur to these people. Those bugs never get fixed, which eventually causes me to abandon the product. They are their own worst enemy.

Also, to head off the tiresome "customers don't know what they want" and "customers lie" chestnuts. First, drop the contempt. You will not build a great product if you hold your customers in contempt. Next, don't ask for feature ideas—all that does is get people to make stuff up in order to please you. Instead, ask what problems they need to solve. Learn how they do it now and look for possible improvements. Then, work collaboratively on a solution. Nobody can assess a solution until they have it in their hands, however, so work incrementally and small, release often, and adjust based on feedback. You will all get it wrong more often than not, but that's just part of the process.

The people who fail often follow the waterfall model of one-time, up-front requirements gathering, then building exactly what's specified. Those up-front specifications are never correct. So-called spec-driven development, when based on a single unvalidated idea, will fail. Always.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Code is, in and of itself, not valuable. In fact, if the code is not making the product better in the eyes of your cusomtomers/users, then it's a liability—money spent without a concomitant return. Consequently, any measure of code volume is worthless unless it can be correlated with value.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Product work is not a distraction from the work; it _is_ the work. There are many programmers who don't seem to get that. We are building products, not (just) writing code. A pile of code that doesn't come together into a product is a liability, and code that doesn't make the product better is equally worthless. Code is, in and of itself, not valuable.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I've been hearing people lament that, if AI replaces junior programmers, then how will we get new senior programmers when nobody's in the pipeline? If the AI is good enough to replace a junior programmer, then it will soon be good enough to replace a senior one, so the mentoring question is moot, at least when it comes to coding.

However, I see myself as a technically proficient product developer, not a coder. Coding is only a small part of product engineering. AI cannot do most of what's left. There are plenty of both juniors and seniors in the product-engineering space, so I'm not worried.

I see nothing wrong with eventually leaving coding to the machine, though the AIs are not there yet—even Fable makes occasional horrific mistakes, and it still needs considerable guidance. The transition seems inevitable, though. That said, there's plenty to do, even if we drop the coding altogether. The people who hold onto coding as the only thing that matters will be left behind.

So, we, as an industry, need to stop wringing our hands about coding and pivot toward product development as a whole—something we should have been doing all along, but are now forced to do. Of course, that means that people (or neurodiverse teams) will have to actually talk to customers 😄. It's a brave new world.

It's time to expand our notion of what software engineering entails beyond mere coding. The role of the technical product-development engineer is not going away; it's on the rise, in fact.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

You do not build trust through estimation. You build trust by delivering. I've found that once I start delivering something small but useful every day or so, people stop asking for estimates. Managers no longer need estimates and milestones to monitor progress because they can see the progress with their own eyes. Every day.

Transparency trumps opaque process every time.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

A "story" is not a code word for some random bit of work. Thinking of it as such is a classic example of Larman's Law in action. People cannot imagine a new way of doing things, so they twist the new approach into something that looks like what they do now. It's a complete lack of imagination coupled with the mindless belief that there is one true way to do things.

People who cannot imagine anything other than working from a detailed up-front waterfall specification will turn everything into a detailed up-front waterfall specification.

A story is not a specification. Period. It is a description of the users/customer's work. It does not describe any aspect of a computer program. It describes the domain. The point is that, when we focus on the story, we build things that provide direct value to the users/customers. When people turn "story" into a code word for a mere task, they lose the value focus, and thus the entire point of using an actual story.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

The notion of "writing a user story" strikes me as wrongheaded. Nobody sits down and writes a user story as if they were an author writing a piece of fiction. (The fact that many so-called stories are indeed fiction is the topic for another post 😄).

Nobody writes stories. Not you. Not users. Not some PO/PM. Instead, you have a conversation. You collaborate with your users. You might write down a few words to remind you what the conversation was about (that's plenty for deciding what to work on next). When you decide to start the work, you have another conversation to work out the details. You may take a few notes to jog your memory, but that's it.

You capture stories from a conversation, not write them.

The people who "write stories" are invariably doing waterfall up-front requirements gathering. They are writing a detailed waterfall specification. I don't do that. I certainly don't ask my users to do that. Nobody needs to do that. The requirements/specs are always stale by the time implementation rolls around; not worth the virtual paper they're written on.

So, don't write stories. Instead, have a conversation. Collaborate. Take a few notes.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

A backlog is a collection of work items that you do not have the capacity to build. (If you did have the capacity, you'd just build it.) It's a black hole where work goes to die. The only way to alleviate that logjam is to increase capacity, either by adding people (usually doesn't work) or by improving how you do the work (most companies won't). Consequently, the backlog always grows over time, filling with work that will never be done.

AI might fall under the "improve" category, but in practice, it doesn't seem to. My theory is that this is Parkinson's Law in action—work expands to fill all available capacity. If you add AI to the mix, the backlog grows faster than the amount of work removed. I've also seen people use AI for work not specified on the backlog at all—they just get carried away by the "productivity," adding unspecified feature after unspecified feature as they work. If you define "productivity" as removing backlog items, the AI gets you nowhere.

My solution is to get rid of the backlog altogether. Just throw it out. All of it. Now. If it's important, it will come back.

Then breathe a sigh of relief.

Then create, not a backlog, but a fixed-size input queue for Engineering. The size is just large enough so that, when you need something to do, there's something to do. A couple of weeks' work is plenty. Then chisel that size onto stone tablets and guard it zealously. Nothing goes on unless something comes off. Period. (This is called a work-in-progress, or WIP, limit.)

Nobody, not even the CEO, can violate the size limit. If some piece of do-it-last-week-or-the-sky-will-fall work comes along, you need to remove a queue item to make space. A discussion with whoever inserted that item will ensue. That's a good thing. The queue must hold the most valuable (to users/customers) work, and if everything is "most valuable," nothing is. The size limit guarantees high value.

#NoBacklog

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I am so sick to death of people talking about the "competitive advantage" that AI gives you. That's complete and utter hogwash. AI has zero impact on competitive advantage. Competitive advantage comes from building a high-quality product that people want to buy. It comes from talking to customers, understanding their problems, and building what they need. AI adds nothing. It just helps you type faster. (And there's ample proof that "first to market" is also BS, so typing faster is of no help, either. The products that win are usually the second or third ones—the ones that fix the kluges and security holes and corner cutting and bad thinking and ignoring customers that were an inevitable result of that rush to get it out the door.)

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Judging by posts I've seen, it's time to talk about MVPs. There's a lot of misunderstanding of the notion. People take the acronym too literally. There are two definitions of MVP. The earlier one was coined by Frank Robinson, and aligns with what people think (that the MVP minimum product), but the more useful definition is the one Eric Ries describes in his book "Lean Startup." I think of Ries' MVP as:

the Minimum thing that tests the
Viability of a
Product idea.

It is not version 1.0 of your product. It's not a product at all, in fact. It's a test. If the test passes, the idea is viable, and it might make sense to build v1.0. The whole point is to not waste time building something nobody wants.

Notice that my definition didn't say "the minimum thing you can build" because the ideal MVP doesn't require any building at all. The MVP for DoorDash was pizza delivery, which tested the viability of home food delivery. No coding required. A second MVP might test online ordering with a single-page site featuring a minimal menu for a single restaurant. The MVP wouldn't process any orders—it would just forward them to a human, who would handle everything else. Again, the idea is to test the viability of a product idea, NOT to build a product. The MVP is a precursor to building. Only after those two tests (MVPs) gave you satisfactory results would you consider building something real.

MVPs must be very small. In one of his online talks, Ries suggests that you come up with the smallest possible set of features. Then cut that in half, then cut it in half again, then cut it in half one more time. Put in terms of testing theory: test only one thing at a time.

The next issue is quality, and there are two schools of thought. One is that you want to get the MVP into your potential customers' hands as quickly as possible, so using Vibe coding or sloppy manual coding to create a throwaway MVP is fine. The key concept in that last sentence is "throwaway," though. This approach effectively bets that the idea will fail, so you want to expend the least effort.

The second school looks at the MVP as the core part of a walking skeleton (the beginning of an iterative development process). Here, you're betting that the idea will work. Given that the MVP will be at the core of a real system, it must be high-quality. The feature set is very minimal, so the MVP still comes together very quickly, but the code is real, production-quality code. My experience is that high-quality code goes together faster than low-quality code, so the quality actually helps.

These two approaches cannot coexist. It's a disaster in the making to use a low-quality MVP as the core of a walking skeleton. You'll never overcome the corruption of the putrid core.

So, I'm a huge fan of the (Ries-style) MVP approach. The best way to get a product to your customer sooner is to not waste time building features they don't want. The MVP helps with that.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

The very existence of options and settings is usually a sign of indecisiveness and poor product research. They tell me the programmer hasn't done their homework (e.g., talking to customers), so they have no idea how something should work. The programmers respond by implementing everything that pops into their heads and providing a setting to choose. In other words, they are pushing their work onto their users/customers. If nobody ever changes a setting (and for most programs and most users, that's almost all of them), then the setting shouldn't exist at all—creating them is waste: time and money down a hole.

So, make a decision and get on with it, but also get feedback and adjust. (Apple does the former, but not the latter. That arrogance is responsible for most flaws in the Apple UX.) If you don't have enough information to make a decision, then you need more conversations with your customers/users, or at least with your product people. It's a huge problem if a product person can't answer a reasonable question within a minute or two. It's their primary job to answer questions, not attend meetings. Async communication is a disaster in this scenario because the code will have been written long before you get an answer, and the odds of a correction are minuscule.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

A user story is not a code word for specification or a requirement or any description of work. It is not a ticket. It is not a to-do item. It is not something you can build. The fact that the term has been corrupted by the Jira-slinging ticket-money pseudo-Agile Scrummy culture is a real shame, because it's a valuable concept:

A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification. It cannot be estimated. It's the topic of conversation that we have with our users/customers to understand their problems and collaboratively develop the smallest, best solution. The story is not the solution—it's the beginning of the conversation you have to arrive at the solution.

A story describes our users' work, not ours.

The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful. By working on the software one small problem at a time, we guarantee that every release does something useful.

People who talk about user stories being dead never understood what they were to begin with. You cannot build software without them.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Yesterday, I posted that the "fail fast" mantra doesn't sit well with me[https://t.co/1xkTyg5uYq]. One thing I don't like about that maxim is the framing. To me, everything we do is an experiment. In the case of a product development, we have a hypothesis ("this change makes our users' lives better") that we need to prove or disprove. Both of those outcomes move the product forward. That is, experiments don't fail—all outcomes increase our knowledge and understanding. As one of the comments on that original post said, our goal is to "learn fast."

As with any experiment, we want ours to be as small as possible, ideally testing one variable at a time. Practically, that means that if the hypothesis turns out to be incorrect, we have less of a mess to clean up. It also means that we can leverage what we've learned sooner. There's no failure at all in this process, however—just learning. In both cases, the product moves forward.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

A periodic reminder that leadership and management are two entirely different things. Calling a manager a "leader" is an appalling bit of doublespeak. You cannot appoint or assign a leader. You cannot be promoted through the ranks to a "leadership position." You cannot learn leadership in a two-day class.

Leadership is about inspiration, not power or influence.

Leadership is something you are, not something you do. It is *really* not about telling people what to do, particularly in the guise of "helping." That's, at best, patronizing, and at worst, bullying. People in a position of power cannot "suggest" or "guide." Those so-called suggestions are _always_ directives, no matter how soft the glove you wrap around the iron fist. The power dynamic forces it. Inspiration is neither power nor authority.

People lead by providing an example of a better way of doing things. They demonstrate how one's life can be improved by being a better person and by treating others with trust, respect, and dignity. Leaders live by their ideals.

Honestly, I find even the term "leader" to be suspect. True leaders do not have "followers." That's describing a cult, not a healthy relationship. Instead, they provide an example that people think is worth emulating.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I keep reading about things like detailed up-front Sprint plans, about "failed" Sprints, about people panicking when a Sprint doesn't go according to plan, etc. There is no agility in that thinking, whatsoever.

A Sprint is NOT a mini-waterfall with a detailed upfront plan that specifies the work you must complete. Treating it as such violates many Agile principles, including those of Scrum, because that approach does not accommodate, much less welcome, changes mandated by things we learn as we work.

The Sprint Goal, for example, is NOT "to complete X stories." Rather, the best goal is to move the product in a focused direction that the users/customers find valuable. Any movement in that direction is a success. The goal defines the focus, not a specific set of tasks.

This thinking extends to the stories as well. A story identifies a user/customer's problem. No more. It is not a waterfall specification. Your Sprint goal is to move incrementally towards a solution to that problem.

Similarly, a Sprint plan is not a detailed specification of something you must build and how to build it. Sure, do some thinking about building at the beginning of your Sprint, but plan just enough to start, not to finish, the work. Adjust that plan as you build, release for feedback, and learn.

You say that you only release once at the end of the Sprint? Where is the agility in that? Release at least daily. Getting feedback after the work is complete (in a Sprint Review, for example) is a huge source of rework waste. You wasted time building the wrong thing, and you waste more time fixing problems when they're no longer easy to fix. You're at least doubling the time required to get a solution into your customer's hands—probably more.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I keep hearing about "the Agile methodology." FWIW, "Agile" is NOT a methodology, process, or framework. In fact, more often than not, those things are an obstacle to agility. Backlogs, SMs, POs, Sprints, Sprint Reviews, Kanban boards, Scrum boards, definitions of done, definitions of ready, daily Scrums/standups, any mandated or required meeting, optimizing for output or capacity, accountability, team-level management, estimation (including story points), pushing work onto the teams ... NONE of these have anything at all to do with Agile. Of course, an Agile team can do those things if they want, but they are neither mandatory nor necessary.

What is necessary is putting people first (including trusting them to do the work in whatever way they see fit), getting working high-quality software into people's hands quickly (daily is good), collaborating (both on the team and with customers), and welcoming change at any time, even (especially) during development. Also, continuous improvement (maybe with retros, maybe not) is assumed. Anything you can do to further those ends is Agile. Period.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Making business projections is important, but you can do that entirely without traditional estimates. To me, an estimate is an analysis of a specification. You can make predictions from estimates, but the predictions are not reliable. For one thing, every time the spec changes, the estimate changes, and no business wants a moving target. So, what's the alternative? I think of a "projection" as something you do by measuring the work—average stories completed per unit time (throughput) and average idea-to-customer's-hands time (lead time)—and then extrapolating from those measurements. No specification is required. The latter approach is a very Lean way of thinking about things and turns out to be much more reliable than estimation. If this is all new to you, Dan Vacanti's "Actionable Agile Metrics…" is a good introduction to Lean metrics.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Trust is built (and competence is demonstrated) by asking, not answering, questions. Except for the extremely shy, anybody so arrogant that they never ask questions is inherently untrustworthy. Who knows what they'll do or say to shore up their ego? And truly competent people know full well that they are not infallible and don't know everything, so they ask plenty of questions.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I don't know that you can have an agile team in an in-agile org. The best case is that you'll waste vast amounts of time-fighting to do basic things. Of course, any team can adopt some of the tools in the Agile toolkit (e.g., TDD, mobbing), and those will help you be more effective, but they won't make you flexible, nimble, or able to welcome change. It's not about the tools.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I can't emphasize too much that when you work in small increments and frequently deliver small but valuable changes, you will always have something to sell, even if money is tight. One of the points of working this way is to reduce risk and bring in revenue sooner. It's not an "Agile" thing; it's a business thing.