Philosophy of Software Quality


Right click “Save as…”

Slides (view online)
A quality outcome always takes more time and effort than a poor outcome. The universe decrees that it is harder to make a good cup of coffee but trivially easy to make a bad one, so why is it then that, as a profession we continually strive to create better outcomes with less effort? IT professionals seem to be genetically evolved to seek out shortcuts. Inevitably this leads to bad outcomes - but we still do it - all the time. We argue that quality is neither a feature nor a “cross-cutting concern” - but something that should be fundamental to your software development paradigm. Creating a cognitive framework that is geared towards quality outcomes makes some aspects of software and systems engineering not only easy, but obvious. Join David Connors (Director & Software Engineer, Codify) and Joel Pobar (ex-Microsoft .NET CLR programme manager) on an epic epistemological journey from the notions of state vs entropy, integrity vs perceived flexibility, and buy now + pay later. We then take the abstract down to the boots on the ground and show you some real-world examples of how you can select the right toolset for success and improve the delivery and maintenance of projects...

Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.