Does Speed Compromise Quality?

  • This prooves that tech debt will NEVER be fixed http://uk.mobile.reuters.com/article/technologyNews/idUSKBN17C0D8

    The only viable strategy is prevention. Thorough automated testing plays a huge part in that.

  • Wow, need to get back to COBOL.

  • David.Poole - Tuesday, April 11, 2017 12:11 AM

    This prooves that tech debt will NEVER be fixed http://uk.mobile.reuters.com/article/technologyNews/idUSKBN17C0D8

    The only viable strategy is prevention. Thorough automated testing plays a huge part in that.

    I think it's a perfect example of tech debt occurring naturally over time and all you can do is pay your mortgages to avoid ending up like these companies. They're putting out fires on systems that could've been continually maintained and thus have been modern(or at least still relevant) but instead they're paying a high price to just keep the systems running. Add the lack of new usability features in the software and it makes even less sense to not maintain your systems.

  • For me, this editorial just highlights that DevOps is a culture. Maybe one that encourages tools and processes such as TDD, CI, CD etc. but still simply a culture. If you apply the aforementioned techniques without the cultural shift then you will just be highlighting the issues of the current culture is a different manner.

    Gaz

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

  • I think that assuming there is a correlation between how often someone releases and the number of bugs is as short sighted as the media claiming trucks are responsible for terrorism.  #NotAllTrucks indeed.

    If we look at what bugs Turbo Tax fixed, or what code was changed, as they made over 100 changes during tax season, my guess is that the majority were the minor changes the government makes in tax rules over time, which hardly qualifies as "development".  Most software is complex overall, but also contains areas of low complexity.  To suggest that you can make a change in complex code is two minutes requires one to ignore common sense.  Is there any relation to how senior the developer is?  How about how often he has worked on that section of code?

    Writing code is complex, suggesting that doing a complex task faster results in higher quality (without regard to all the other factors involved)  is ridiculous.

    Dave

  • It's all fun and games until a hacker breaks in and leaks your data.

    Look, trumpeting automated testing is missing one critical point. Yes, automated tests *help*, but they Do. Not. Solve. The. Basic. Issue.

    Automated testing cures the known knowns, might do something with known unknowns but by definition can do squat all against unknown unknowns.

    Case in point, 0-day vulnerabilities. With all the compiler checks and automated tests in the world these "bug reducing" companies are hacked with embarrassing regularity. Bugs abound *still*.

    You depend on automated testing and you're going to catch the bugs you know could happen. The people who write the tests are usually the same ones who write the code.

    What have we learned about programmers checking their own code?

    Exactly.

    DevOps is not a silver bullet. DevOps is a codified way to overdrive your lights.

    Slow down. HIRE A DAMN QA DEPARTMENT. One that knows how to find the weird stuff.

    Don't get me wrong, I love automated testing. As a lone wolf it's one of the few ways I can get *any* testing done, Lord knows the users won't do it. But at the same time I'm keenly aware of just how (in)effective they can be, especially in complex database apps.

  • roger.plowman - Tuesday, April 11, 2017 7:39 AM

    Lord knows the users won't do it. (testing)

    Amen to that!  Even when I can get them to ask me what to test, and then explain to them what to test, how to test it, and why they need to do it that way, they still decide to not test or not test effectively.

    Dave

  • I'm a lot more productive, and I can even code faster with fewer defects, when I have I have a clear set of specifications to work from. Lack of clarity regarding the task at hand causes misunderstanding and indecisiveness.

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

  • I really appreciate the documented improvements you listed, Steve. Sometime when I've got 2 hours I'll watch the video on refactoring code in 2 minutes. I'm guessing they probably go into what different people were thinking a various times about the code, etc.

    Unit testing is very important. I helped bring that to my new job. However, I wonder what purpose unit testing has in an organization such as the one I'm in where there's no interest at all in DevOps and especially no interest in rapid deployment. All deployments must be approved by committee and if that takes weeks, so be it. I'll still do unit testing, but it seems less useful than I thought it would, when I first came here.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work - Tuesday, April 11, 2017 8:26 AM

    I really appreciate the documented improvements you listed, Steve. Sometime when I've got 2 hours I'll watch the video on refactoring code in 2 minutes. I'm guessing they probably go into what different people were thinking a various times about the code, etc.

    Unit testing is very important. I helped bring that to my new job. However, I wonder what purpose unit testing has in an organization such as the one I'm in where there's no interest at all in DevOps and especially no interest in rapid deployment. All deployments must be approved by committee and if that takes weeks, so be it. I'll still do unit testing, but it seems less useful than I thought it would, when I first came here.

    I don't have enough knowledge of your organization to know for sure, but it seems to me that unit testing is always beneficial.  Maybe in time you will be able to point to how you do things, and get your co-workers/managers to learn from you.

    Dave

  • Gary Varga - Tuesday, April 11, 2017 6:01 AM

    For me, this editorial just highlights that DevOps is a culture. Maybe one that encourages tools and processes such as TDD, CI, CD etc. but still simply a culture. If you apply the aforementioned techniques without the cultural shift then you will just be highlighting the issues of the current culture is a different manner.

    yep, well said, Gary

  • roger.plowman - Tuesday, April 11, 2017 7:39 AM

    Slow down. HIRE A DAMN QA DEPARTMENT. One that knows how to find the weird stuff.

    Amen.  But get them to help define tests up front in preference (but not instead of) later on.

    Ive found that specifying the tests early has a vaccine effect.  A certain critical mass results in wider disease resistance in the population.

  • David.Poole - Tuesday, April 11, 2017 11:31 AM

    roger.plowman - Tuesday, April 11, 2017 7:39 AM

    Slow down. HIRE A DAMN QA DEPARTMENT. One that knows how to find the weird stuff.

    Amen.  But get them to help define tests up front in preference (but not instead of) later on.

    Ive found that specifying the tests early has a vaccine effect.  A certain critical mass results in wider disease resistance in the population.

    Waiting to specify the tests only results in 100% of the tests being passed, regardless of how many flaws there are.  You have to define the tests up front.  So not only does it benefit everyone by reducing the number of issues, but it prevents people from being lazy and thus things being missed, resulting in a lot of rework.

    Dave

  • djackson 22568 - Tuesday, April 11, 2017 7:35 AM

    ...suggesting that doing a complex task faster results in higher quality (without regard to all the other factors involved)  is ridiculous.

    This is why I have an issue with the term faster. It is more a question of earlier. Or maybe less delivered quicker. For many people the term faster infers productivity is introduced by coding quicker.

    Gaz

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

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

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