Better Software East Conference

The Better Software East conference is coming up on November 13-18th in Orlando, FL. This conference about ways to improve your software development process is held concurrently with Agile Dev East and DevOps East.

I’ll be speaking at this conference on Thursday Nov 17th about “Evolving from Automated to Continuous Testing” which should be pretty interesting. And the fun part of it is that because I’m speaking I have a discount code you can use to sign-up at the conference. You can register here and if you put in the discount code BE16AH16 you can save up to $200. If you register early before Oct 14th then you can get up for $400 off, so take advantage.

About my presentation:

Testing issues can be a significant barrier to taking full advantage of agile approaches to software development and the emerging DevOps movement. To leverage these development and delivery strategies to their fullest, you need to evolve beyond automated testing to continuous testing. Arthur Hicken discusses the testing and development processes and technology that enable continuous testing. He shares insights on how to close the gap between business expectations and development activities by encapsulating clearly defining development policies for software releases.

Arthur describes how to prevent defects in code and prioritize defect remediation before a release candidate goes live. Explore ways to realistic test environments and simulations—critical features of the dev/test infrastructure—that enable continuous testing. Learn how to create a feedback loop that exposes defect patterns while highlighting opportunities to improve application design. Take back a comprehensive to do list for processes and infrastructure that must be in place for your organization to implement continuous testing and accelerate the SDLC.

About the conference:

Discover the latest in agile methods, technologies, tools, and leadership principles.

Whether you’re new to the agile process and need to get up to speed quickly or you’re experienced and ready to take your team or organization to the next level, our hands-on, in-depth workshops have you covered. Plus, Agile Dev East is held in conjunction with Better Software and DevOps East, allowing you to choose from three distinct programs.

  • Agile Development
  • Agile Testing
  • Agile Requirements
  • Agile Metrics
  • Improving the Process
  • Agile Leadership
  • Lean and Kanban
  • Agile for the Enterprise
  • Calendar

    Keep track of my calendar for other events – it’s over there on the right somewhere ——–> and don’t forget to register here and use the discount code BE16AH16. In the meantime you can follow the conversation about the conference on Twitter, Facebook and LinkedIn using the hashtag #BetterSoftwareCon. See you there!

Software Safety Keynote EuroSPI 2016

I was honored this week to have the opportunity to present a keynote session at EuroSPI 2016. The title of my presentation was “Software Safety and Security Through Standards” and I discussed one of my favorite soapboxes. That is the idea that software development is often less disciplined than it should be, but it doesn’t have to be. We can and should develop software as an engineering discipline.

One of the key ways to start down this path is to implement coding standards properly. Too many are trying to use coding standards late in the process as a way to find bugs, rather than a way to flag improper methods of coding early on. While the former is cool, the latter is far more valuable.

The adage that “you can’t test quality in a product” is well known, but for some reason in software we think that you can indeed test quality into an application. The same goes for application security, perhaps even doubly so.

In order to break out of the current cycle of code, deploy, fix, redeploy we have to start doing things differently. We have to build a more mature software development process and static code analysis is the way to build upon the body of knowledge and best practices available.

Slides are below. Let me know if you have comments, questions, suggestions. And thanks to everyone at EuroSPI and ASQ for putting on a great conference and allowing me to participate. These are great organizations to get involved with if you’re serious about software quality. I encourage you to check them out.

Keynote at EuroAsiaSPI2 2016 Conference

If you’re going to be in Europe in September, I’ll be speaking at the EuroAsiaSPI2 2016 conference in Graz, Austria on September 15th.

EuroAsiaSPI2 is also known as European & Asian System, Software & Service Process Improvement & Innovation. The EuroAsiaSPI² conference presents and discusses results from systems, software and services process improvement and innovation or SPI projects in industry and research, focusing on the gained benefits and the criteria for success. This year’s event is the 21st of a series of conferences to which international researchers and professionals contribute their lessons learned and share their knowledge as they work towards the next higher level of software management professionalism.

I’ll be speaking on Software Safety and Security through Standards

Abstract:
Software has moved from the desktop in just about everything we touch. From smart thermostats to infusion pumps to cars software is pervasive and growing. These so-called “things” from the Internet-of-Things are increasingly carrying more logic and with it a larger risk of failure. Many of these devices are using in safety critical areas such as medical and automotive where they have a particular potential for bodily harm.

Most companies that have been building devices rightly view current software development as an almost insane group of cowboys and chaos. But there is hope, software CAN and MUST be treated an engineering practice. Coding standards move us from the build, fail, fix cycle back into a design, build, deliver cycle with high quality, safety, and security.

As it turns out, these same standards also provide benefits in the areas of cybersecurity, doing double duty. We will explore how standards help us move from finding bugs to building more robust software, how to prevent problems in the first place by proper coding, and how to leverage the efforts of others by using common accepted industry standards such as MISRA to achieve this goal.

To attend you can register here.

Understanding Open Source Licenses

Open source projects come with a wide variety of license types. Some of them even conflict with each other. They include things like restrictions against commercial use, a requirement to distribute the source code, proper attribution, and more. If you’re using several different open source projects, it becomes an administrative headache to make sure you’re in compliance with the various licenses involved. Some projects even have multiple license choices and you need to understand which of the license you should choose and which you can ignore.

In order to minimize the risk and the effort to enforce compliance, it’s worth looking at the license associated with an open source project before adopting it. Some of the pitfalls include:

Pitfalls

Ambiguity: Some licenses can be ambiguous because they are drafted without benefit of professional legal advice. Make certain the terms fit the conditions necessary to your business. Just because a lawyer didn’t draft them doesn’t mean you can’t seek legal advice before using a project, so do it. This sounds like a lot more work than it actually is, because you don’t have to review every type of software license for every project you’re coding. You only have to review every license type that you want to use. Once you’ve accepted for example the MIT license (currently the most popular open source license) you’re ready for all projects that use open source components with that license.

Jurisdiction: Some licenses have a jurisdiction that may be inconvenient – for example if they software is governed by EU laws and you’re an American company this can be problematic if legal issues arise, whether around intellectual property or liability. In some cases, some licenses have omitted jurisdiction info leaving you open to challenges in venues that may be costly or difficult for your business.

Unintended open source: Some licenses such as the GPL require that all derivative works have the same restrictions as they do, meaning that you can be forced to open source your project if you use them. If you’re working on proprietary software this isn’t a viable option.

Patentability: While not all licenses conflict with traditional intellectual property rights such as patents, some of them do. If intellectual property (IP) is important to your business make sure the software licenses you use don’t restrict your rights.

Copyright: There was a court case a few years back over whether or not the owner of an open source project can enforce their rights against someone who uses their project. On appeal it was determined that they can. In other words, violating an open source license can be legally actionable in the United Sates – see Jacobsen v. Katzer.

License Types

Below are examples of some of the most common open source licenses in use. More detail can be found at https://opensource.org/licenses and advice on the different types of licenses can be found at http://choosealicense.com.

GNU GPL: Comes in many versions, currently GPLv3. This is called a “copyleft” to differentiate it from “copyright”. Using this license means that you must share the source code to your own work using the project under the same terms as the original project, for example making your own code available. Includes an express grant of patent rights from the contributors. Used by Bash and GIMP. This works well if your own project doesn’t get distributed, or if you don’t mind open-sourcing your own work.

GNU LGPL: Similar to GPL above, but makes a distinction between “based on” and “uses” to determine whether or not you have to share your own source code. “Uses” means you don’t have to share the code while “based on” means that you must.

Apache: Comes in multiple versions – currently v2.0. It’s a permissive license that lets you do pretty much whatever you want with the code as long as you don’t hold the contributors liable and provide attribution. Also contains an express grant of patent rights from the contributors. Used by Android and Apache.

MIT: Simple license that lets you do anything you want with the code. The only limitations are that you must provide attribution and you cannot hold the project or contributors liable. Currently very popular, used by jQuery and Rails.

Summary

In summary, vibrant active open source projects with reasonable licenses that are compatible with your business can be a great asset. Take the time before committing to a project to make sure that its licensing will work for you.

Ranting about Software, Security and Tech