Skip to main content

View Diary: A Software Engineer's take on (145 comments)

Comment Preferences

  •  "Subject matter experts" are not (0+ / 0-)

    database engineers or acceptably knowledgeable for how to structure programming systems.

    "Disruption" is a common excuse for running noncompetitive money-losing systems.

    The old systems do their financial management functions well enough. Process management, not so much. Quality and value go lost so the whole company becomes vulnerable.

    The usual result is that the laggard is absorbed in an M&A takeover. Crappy management systems make the company a target.

    •  I've done process management (1+ / 0-)
      Recommended by:
      Oh Mary Oh

      Years of it.  I've even made it work.

      I've seen theories come and go.  Continuous Improvement, TQM, ISO 9000, Six Sigma, "Do more with Less", avoid hidden factories blah blah blah.  Trained in all of them at one time or another, actually did the "Black Belt" thing for a couple years.

      The bottom line is that there are always "low hanging fruit" after a few years of using any methodology that are improved by using some other methodology.  Turns out different categories of processed do best under different process engineering.

      To use software design as an example, in an environment of rapidly changing requirements but deep business engagement with a fairly robust test and prod environment that can tolerate rapid rollbacks of faulty code, Agile methodologies have clear advantages.

      In an environment with apps where it isn't the end of the world if an outage occurs, where security is normally important but not critical and where the expense of properly staffing and equipping a data center (or multiple for disaster recovery) is prohibitive, Cloud architectures, even with current limitations, have clear advantages.

      In an environment where requirements are stable (change slowly) but extremely complex, where downtime costs the company money instantly or leaves it exposed to lawsuits or regulatory punishment, old-school waterfall methodology combined with a robust QA and six-sigma like process monitors and statistical controls truly shine.

      If you do not understand the advantages of all three, I question your understanding of process engineering.  

      My company uses all three broad approaches, with variations for specific situations, and we're the kind of company that crushed all of our opposition by executing better than they did most of the time, while being resilient in years when we made bad decisions or the environment went toxic (as in 2009).   We're a tech company, so it isn't like we're limping along by having the secret Coke formula, an addictive chemical in our products and 80 years of marketing a brand.

      So yeah, even though we change slowly in some areas, there is actually a reason for it, and it has not affected our agility where it matters.  Having a safe place to stand means you're more able to shift your weight without disaster. does not fit neatly into any of these categories.   It was developed under conditions where only Agile does well, but it really is the kind of application that normally falls under massive production control for safety and reliability (similar to the third example).   Rolling out an app like that in a hurry means the usual evolution to true requirements happens after go-live, with a process very similar to what we're seeing now.  It ALWAYS sucks.    Apps like that usually aren't perfect on release because it is pretty much impossible to understand it well enough while developing it if nothing like it exists already.   But rushing the process to an arbitrary deadline while being extremely vague on requirements, expected user base, etc is pretty much guaranteed to experience problems.

      • was set up to fail. (0+ / 0-)

        The left over moles from the Bush Administration got it rigged as a 55 contractor clusterfxck.


        That's utterly absurd. And these issues have nothing to do with AGILE vs. waterfall vs. the POC-with-stages approach favored by USAF Systems Command and Oracle Consulting.

        (I don't see "cloud" as an architecture except at the hardware and connectivity functions.)

        Identity Management should have gone to 1 vendor.

        The rest of the web site was a 120-day project with no significant complexity -- it front-ends existing systems and there is no need for it to write into their tables or do extra logical filtering.

        All would be well getting reports on sign-ups back at end-of-day.

        55 @&^%$%^^&*amned separate contractors............

        •  I agree it was set up to fail (0+ / 0-)

          I'm not sure that was avoidable given that Congress has oversight and half of it is hostile to the idea.

          I think we can agree that procurement was completely screwed up, the whole thing was sandbagged until after the 2012 elections and the entire project started entirely too late.    Given those front-loaded problems it's rather surprising anything was functional at all.

Subscribe or Donate to support Daily Kos.

Click here for the mobile view of the site