Get ready: Windows 8 is coming. For enterprise software developers, the new Metro interface is likely to be a curiosity, but one which you’ll be facing soon enough. The impact that Windows 8 will have on you and your development team will depend on whether you’re writing desktop software for internal consumption or for outside clients/customers.

Let’s talk about internal software first. If your organization uses Windows desktop/notebook computers, it’s very likely to have a heterogeneous mix. Maybe there’s some Windows 7. Some Windows Vista. Some Windows XP (with die-hard employees refusing to give up their Pentium mini-towers). Perhaps even a few Windows 2000 instances, although that’s increasingly rare.

Unless you work for an organization that will move wholesale to Windows 8, your relationship to the Metro user interface and the new operating system will be best described by two words: “regression testing.” Stay on top of the Windows 8 hubbub, but certainly don’t expend any significant resources to learning the new APIs and coding models.

If your applications are used by external customers, it’s a different story. For competitive reasons, customers will expect applications running on their shiny new Windows 8 touch-screen desktops and tablets to have the Metro user interface. It’s your job to meet those expectations.

Fortunately, on first blush it should be relatively easy to retrofit or wrapper existing Windows applications to play nicely with Metro. If you have a complex application, there does not seem to be a compelling benefit to re-architecting or rewriting your software to use WinRT. The exception would be applications that are very interactive and dependent on the user interface. In any case, it’s critical that applications be able to work with both touch-based Metro and traditional keyboard/mouse environments.

Finally, if you are building Web applications, be aware that Windows 8 will include two separate Internet Explorer experiences. Back to regression testing again: Customers will want to be able to use the Metro browser. Be sure that they don’t feel like second-class citizens.

Windows 8 will be upon us next year, further complicating our desktop development experience. Whether we like it or not, most of us will need to support it. So, let’s get ready.

Stop making the same old mistakes
We’ve been writing about software security flaws for 11 years, and, you know, when it comes to the developer’s role, not much has changed. But it needs to.

You can rattle off the list of the biggest sources of vulnerabilities. Say them with us: SQL Injection. Cross-site scripting. Insecure direct-object references. Failure to require strong passwords. Parameter reflection. Unchecked buffers. Undiscovered backdoors. Subversion of access control lists. Improper sharing of trust relationships. Flaws in cryptographic implementation. Failure to authenticate. The list goes on.

While certainly there are new vectors for attacks, such as mobile apps or rich Web 2.0 applications, the basics haven’t changed. Yet study after study, analyst after analyst, say that developers are making the same mistakes they made in 2000. That they made in 1990. And earlier.

What will it take for software development managers to create a culture of code quality that includes secure programming practices? We can’t claim that managers are unaware, or that executives are unaware, or that programmers and testers are unaware. These are known issues, and the proper security practices are also known.

Certainly one solution is automated testing. There are many vendors who will happily sell you static analysis tools, and if you’re not using analyzers, you should be, either commercial offerings or open-source tools. Equally, there are many who believe that the best way to enforce the use of those tools is to build them into the code check-in process. It’s hard to argue with the effectiveness of that; programmers, like all other humans, can make mistakes. Automation can help ensure that most coding errors are caught.

Automation isn’t the only answer, at least not automated testing. The real challenge is to teach, inspire, wheedle and cajole programmers to make sure that the errors aren’t introduced into their code in the first place. (If someone is a poor writer, you don’t improve their skills by adding spell-check software, after all.) Testing software is a safety net, not a substitute for an awareness of secure programming practices—and a culture that prizes getting it right in the IDE.

One suggestion is to combine carrots and automation. Develop motivational programs to reward programmers for coding things right the first time. Think about those signs you see in industrial workplaces: “XX Days Without an Accident.”

What if you posted signs saying “XX Days Without a Coded Security Vulnerability,” reviewed every caught vulnerability in a staff meeting, and celebrated milestones? When coupled with check-in-based automated static analysis, positive motivation may do the trick.

We’ve known about these software problems for years. We’ve put up with them for years, trusting static analysis tools and good fortune to save us from disaster. If you want more secure software, change the culture.