Tag: republish

  • Republish: The Change Failure Rate

    It’s President’s Day in the US and I have a day off, where I’m coaching volleyball up in Greeley, CO. And slightly worrying what maintenance might be waiting for my back at the ranch.

    You get to re-read (and re-comment) on The Change Failure Rate. Interested to see if people view the world differently after a few years.

  • Republish: How Much AI Do We Need?

    I’m back today from holiday, but gone tomorrow. As I try to close down the year, I decided to re-run How Much AI Do We Need? as it was an interesting look back at a piece from 2020, when the LLM/GenAI hype wasn’t a thought in most people’s minds. Instead, the AI systems were simpler and more focused on specific siutations.

    I find myself thinking back a bit and thinking about the world back then and re-reading the linked article. In that one it seems like “smart” is more about better communication and coordination in the kitchen, and less about the appliances having any intelligence. Some of the image recognition items might lightly be called AI/ML work, but most of the added features aren’t.

    Re-read the piece and article and think about how much AI do you need, or want.

  • Republish: Choosing Sequences Over Identity

    It’s the start of the holiday season for me. I’m off all this week and a few next week, so I’m really done for the year.

    You get to re-read Choosing Sequences Over Identity.

  • Republish: Over-Engineering

    It’s Black Friday, and a holiday in the US. I’m off today, no idea what we’re doing, but probably some horse chores and taking it easy.

    You get over-engineering as a republish. I realized it was never on this site, so here it is:

    Over-Engineering

    This editorial was originally published on Jul 15, 2009. It is being re-run as Steve is on holiday.

    I stumbled upon an old blog post by Neil Davidson that he recycled via Twitter. It was about design and how things bloat. In the post he references another blog by Moishe Lettvin , who worked on the Shutdown menu in Vista. Reading that post, I was amazed to find that 8 people directly and 43 people indirectly contributed to that feature over a year.

    Really?

    At first I had the amazing response that most people probably have of MS is obviously so (insert your four letter adjective here) blanked-up, no wonder Vista was late. However as I read through the comments, I saw so much disagreement over how the feature works, should work, compares with OS X, and more that I’m not sure so this was a year of development time wasted. (Note I don’t know the man-years spent on this, but I bet it’s > 1).

    I haven’t built a lot of software in my career, especially large scale or shrink wrap software, and so perhaps I don’t really understand things. However I do think that we tend to over-engineer too often. I see people that try to design in every contingency, as well as think of every possible places things might go wrong. I have a simple mantra for you folks:

    You can’t do it. Get over it and ship something.

    It sounds simple, but it’s not. But it’s not necessarily naïve. I’ve seen too many people delay releasing something, trying desperately to get things right. They’re never right. They’re also never done, so you might as well ship something that’s 80% right and then plan on fixing it right away.

    I know some people will disagree and say that things should be built right the first time. I don’t think they ever are. They can be built well, but they ought to be built quickly, and with a design that expects changes to be required in  a relatively short time frame after they’re released. This doesn’t work for all software, but I bet it works for a large class of applications that aren’t on the scale of SAP or Windows.

    We can learn to code better, build more secure and stable software, but I don’t think we’ll ever cover all the bases. So why try? Build something that works most of the time and then refine it from there.