Are You a Tech Company?

  • Comments posted to this topic are about the item Are You a Tech Company?

  • I feel the company I work for is becoming a technology based company, but at the heart we are in the digital marketing space as an agency that offers both products (i.e.: data products) and services (i.e.: digital advertising). Being we are in the digital space, technology is what powers us to do business. The issue is how much of that technology is growing within an organization that is not mostly made up of technology people versus people who use technology to function.

    Prior to that, I worked in AAA video game development. We were very much a technology company. It took 3 - 5 years to come to market with a product that took tens of millions of dollars or more, and a very large international development team. Due the the nature of the products, which were massively multiplayer online games (MMOG), making mistakes costs us a lot with our customers and became public news with popular gaming websites worldwide.

    Although we had some pretty advanced patching systems that streamlined client updates to our customers, the size and complexity of the product still made it difficult. The software itself due to it being a high-end game made patching extremely large for most customers. The size of the game world with all it's game assets and game systems made testing everything also hard after every update. Thus, the chance that changing one thing also impact something entirely different happened a lot and the cost of doing that was extremely high.

    I think it really depends on the business and the technology they are building. In game development, it's not that you cannot learn from your mistakes, it's that the size of the product and delivery process that makes it hard to change. Anyone can say that learning from your mistakes will help us going forward. Very little people can actually put that into action and implement change that not only improves the process going forward, but actually gets all the stakeholders on board with that change. Getting those stakeholders to take the risk is easier said than done.

  • A recent client had come to terms that it actually was a technology company but refused to change how the organisation perceived themselves. Thus they acknowledged where their true value lay but didn't resolve to protect and enhance it.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Haste makes waste.

    Yes, it's good to issue a *fix* rapidly. However, I am profoundly unimpressed with the "we gotta release it every X months or we're toast" mentality when it comes to new versions and new features. Yes, in an ideal world it would be wonderful to get new features every couple of days (assuming you needed/wanted/lusted after them) but in reality software is complex, growing ever more so by the day and the number of possible interactions grows "plexically", not just exponentially. (ie 10^2^100)

    In other words, science hasn't kept up with marketing--which is nothing new, of course. 😛

    Constantly release buggy software products and who's going to trust you, no matter how fast you start releasing bug fixes? Isn't that how MS got the reputation for getting it right the third time? In the days of long release cycles?

    Now think about the typical non-tech company and their in house software team trying to do rapid releases, with a small development team, no dedicated QA people, and no beta testers.

    Yeah. Living in interesting times... (laughing)

    Slow down the cadence, people. You're overdriving your headlights and there's MOOSE out there!

  • roger.plowman (9/20/2016)


    ...Slow down the cadence, people. You're overdriving your headlights and there's MOOSE out there!

    The mistake is that people are trying to do too much too quickly. Small and quick releases is manageable in most circumstances. This does not mean that any step is missed either.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • We have a pretty regular once-a-month release cycle. But we do allow for a hot fix update when the issue is critical, on an as needed basis.

  • While I agree with the idea that fixes need to be expedited, I disagree with the mentality that the barbarians are at the door. Unless you are working for a major player in a sensitive or highly visible industry, the sensationalism suggested here is not an excuse to 'throw it in now' because somebody might utilize a vulnerability to hack into the system. To say "potentially hundreds, or thousands, of malicious attackers could take advantage of a flaw this week" is simply unrealistic unless you are working in a handful of high profile businesses. That is the problem I see as being more dangerous than the hacker and wasting of more person hours than all but the most sensational hacks.

    Maybe I am being too critical of the choice of words here but does Mr. Jones REALLY mean "We should learn from mistakes, and not try to avoid them" ? I would much rather my staff do their learning through complete TESTING to avoid mistakes instead of 'learning' that their rush to implement a fix resulted in hours of avoidable downtime or data loss and corruption. Testing of the change must be done and not rushed through because of unrealistic panic resulting from sensationalistic claims of vulnerability and fear of catastrophic damage. Even environmental fixes (OS updates/db vendor updates) need to be tested and reviewed within the organization rather than pushing an update out because of a vulnerability and hoping that other internal systems will not be affected. I have lived through too many of the 'push it out and hope for the best' situations at previous employers ...

  • Case in point:

    http://www.nytimes.com/2014/09/20/business/ex-employees-say-home-depot-left-data-vulnerable.html?_r=0


    .. Several former Home Depot employees said they were not surprised the company had been hacked. They said that over the years, when they sought new software and training, managers came back with the same response: “We sell hammers.” ..

    "Shut yaw mouth about hackers and such, becuz we aint a tech company... WE SELL HAMMERS." :ermm: :w00t: :crying:

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Gary Varga (9/20/2016)


    roger.plowman (9/20/2016)


    ...Slow down the cadence, people. You're overdriving your headlights and there's MOOSE out there!

    The mistake is that people are trying to do too much too quickly. Small and quick releases is manageable in most circumstances. This does not mean that any step is missed either.

    Oh, don't get me wrong, I do like the idea of small releases (1 small feature, maybe) but even then that applies to a long standing system that's largely already stable. It most certainly should never apply to new systems (or even major revisions of existing systems).

    I read the article Steve was talking about and it is based on the badly flawed premise "software mistakes have essentially zero cost". That is so breathtaking boneheaded I don't even know where to begin.

    The assumption seems to be that since you can update quickly any mistake is trivial, and while occasionally true it is by no means a safe generalization. Apple's update that nuked external boot drives a while back comes to mind. Easily and quickly fixed, yes. Zero cost?

    Um, no. :hehe:

  • roger.plowman (9/20/2016)


    ...I do like the idea of small releases (1 small feature, maybe) but even then that applies to a long standing system that's largely already stable. It most certainly should never apply to new systems (or even major revisions of existing systems)...

    So no small releases to new systems or newly updated systems?

    For the record I am totally against rushed or pushed releases of ANY size. I do, however, feel that small and frequent releases are both more manageable and easier to successfully achieve. It does require automation of not only testing ad deployment but also of infrastructure e.g. test environments etc.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (9/20/2016)


    roger.plowman (9/20/2016)


    ...I do like the idea of small releases (1 small feature, maybe) but even then that applies to a long standing system that's largely already stable. It most certainly should never apply to new systems (or even major revisions of existing systems)...

    So no small releases to new systems or newly updated systems?

    For the record I am totally against rushed or pushed releases of ANY size. I do, however, feel that small and frequent releases are both more manageable and easier to successfully achieve. It does require automation of not only testing ad deployment but also of infrastructure e.g. test environments etc.

    No, no small releases to new systems (other than bug fixes, of course).

    The reason I say this is that new systems are not known quantities nor are they stable as a rule. So what looks like a small change might in fact have hidden (and large) repercussions that won't be obvious. Especially if the new system is touching old ones...brrr.

    Have several small releases in a row over the span of a week to a new system? Yeah, that's just asking for trouble. You have to give users time to really pound on a system and make sure there are no dragon eggs ready to hatch!

    Every time you add a new feature it introduces a huge array of new interactions. Every time. Multiply that by the number of releases and the numbers turn nightmarish pretty darn quick.

    Add to that most "non-tech" companies don't have QA or adequate testing resources, or even users that are willing to play with a beta system and rapid releases = users using alpha code in production. Not trying to insult anyone, that's just the way the world works.

    Mr. Alpha Code is nobody's friend...

    [Edit: spelling]

  • Testing does no good if you can't dedicate time to fixing the issues before you release. In most cases I've experienced, releasing is still happening because of the agreed upon release schedule. While it would be nice to have that "It's done when it's done" release schedule, some of us are not that lucky and have to release knowing there are issues we'll have to address in later releases. Maybe that's what happened to the recent iOS10 update?

  • xsevensinzx (9/20/2016)


    ...In most cases I've experienced, releasing is still happening because of the agreed upon release schedule...

    Some places triage defects. If the defect is serious enough then the release does not go. This is relevant to releases of any size.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • roger.plowman (9/20/2016)


    ...Add to that most "non-tech" companies don't have QA or adequate testing resources, or even users that are willing to play with a beta system and rapid releases = users using alpha code in production. Not trying to insult anyone, that's just the way the world works...

    I have a different set of experiences then. Also, small and frequent releases <> hack and ship (necessarily).

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • wojnarkj (9/20/2016)


    Maybe I am being too critical of the choice of words here but does Mr. Jones REALLY mean "We should learn from mistakes, and not try to avoid them" ? I would much rather my staff do their learning through complete TESTING to avoid mistakes instead of 'learning' that their rush to implement a fix resulted in hours of avoidable downtime or data loss and corruption. ...

    If your staff are doing extensive testing (unit, integration, system, etc.), then I think they are learning from mistakes. Or are they ensuring code is perfect before they test it? Do they cover all code with tests before they run the tests?

    You're conflating mistakes with releasing buggy software. Avoiding mistakes leads to really slow development. Making mistakes is fine. Just fix them in development/qa.

    The fixing should have nothing to do with production, though some people want that approach.

Viewing 15 posts - 1 through 15 (of 23 total)

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