Building Great Software

  • Comments posted to this topic are about the item Building Great Software

  • Here are some observations:

    - Averages are meaningless right now. Some people do fantastic work with AI, others don't.

    - Personal observation: if you know what you want to build or you have a product owner who knows exactly what should be built and has time to evaluate and test the results, your progress will be very fast. Otherwise that is the limiting factor.

    - However you measure it, my productivity over the past 4 weeks has reached the point that when you calculate it against commits, or KLOC, I did at least 4 years of work in 4 weeks. But I'm an experienced developer and enterprise architect, who is also doing information modelling and understands semantics and AI limitations. This will not work for everyone.

    - Teams slow down performance by at least 3x (independent research) versus a single dev running the show, for the same software. The communication overhead is lethal.

    - "Deep understanding of the problem space, what your customers need, and what helps them work well." - that's what takes time. Building the software fast, however, allows you to iterate through the various solutions with those customers in a week. That makes it a lot easier to get there.

  • I saw a meme this morning that rather fits with some of the editorial...

    The "Museum of Meaningless Metrics," with the curator standing by a display saying "Our newest exhibit."  The line of exhibits had "Lines of Code," "Story Points," "Pull Requests," and the new exhibit, "Tokens Spent."

    I will say, I have started bending and begun using "AI" for some things.  Granted, not for any code / queries I may be writing for whatever reason, but for taking care of some of the drudgework or being employed.  Writing first-drafts of my annual appraisals, "professionalizing" emails, that sort of thing.

    But at least right now, I don't know that an "AI" could come up with a GOOD UI for an application.  It might make a passable UI, but I'd expect there'd be some rather interesting (and odd) design choices.

  • Thanks Jasona, found the meme

  • I've seen several tools that have started as side-of-desk development to make an individual's life easier.  What started as one person's "make my life easier" project grew to become something larger as more people found it useful and asked for additional tweaks and functionality.  Welcome to ShadowIT.

    The original tool (and 1st few modifications) were probably just what people needed.

    The original creator never intended for their "make my life easier" product to end up a mission-critical piece of software.  Eventually, they either move on, or the conversation takes place where someone else has to take on maintenance of an organically grown product.

    The inheritor (formal IT) discovers an organically grown product, quite probably with a confusing hotchpotch of design choices that is hard to read, much less maintain and extend.

    My experience is that there is never enough money/time to rewrite the tool properly, but the powers that be are happy to bleed many multiples of the rewrite costs just to keep it running.

    For me, the key lessons I have learned for writing successful software are:-

    • Whoever specifies the product has to have a comprehensive knowledge of what they want built
    • They need to be really good at explaining it and willing to spend the time to explain as many times as it takes
    • Developers and end users need to collaborate and be available for each other's questions
    • Develop using the company patterns and practices
    • Development and CI/CD tooling needs to enforce code quality
    • Cover everything with meaningful tests

    The 1st 3 are the human necessities, the last 3 are the mechanical necessities

     

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply