Faltering Software Quality and Standards: Why Programmers Should Stop Calling Themselves Engineers

In the current tech scene, it has become common practice to refer to programmers as engineers. It seems that if you aren’t part of sales or marketing teams you are now entitled to being designated as an engineer. However, what has been forgotten over the 50 years of looking to turn software development into a legitimate engineering practice, is that we still haven’t reached the aspiration of being just that: a legitimate engineering practice. Traditional engineers have to go through stringent regulation, certification, and apprenticeships in order to gain the title. This creates an implicit responsibility of providing reliability and public safety. Software development hasn’t reached this point yet – software quality and standards are not universally valued.
So why is the tech industry using the engineering title to describe its technical workers?

Software Analytics: Nine Steps to Create Better IT Budgets

All businesses recognize the importance of developing software within a budget. But how do you put together that IT budget in the first place? CAST has worked with a successful CIO to create a guideline of best practices (>Click Here To Download It<). Saad Ayub, formerly CIO at Scholastic and The Hartford, suggests nine ways analytics supports better IT budgets.

Digital Transformation Keeps Software Complexity from Becoming a CIO’s Legacy

They say “if something works, don’t fix it.” This old adage may be the reason behind why some organizations hold onto legacy systems longer than they should, but it is also the reason why these same organizations struggle with software complexity. In fact, according to the GAO, Uncle Sam spends 80 percent of its $86.4 billion IT budget on legacy systems.
Some organizations choose not to struggle, though. Take for example the story of Pennsylvania-based underwriter NSM Insurance Group. It was reported recently on SearchCIO.com that NSM last year purchased a company that still had a COBOL-based back-office system from the 1990’s.

Highlight Update Brings Rapid Portfolio Analysis to the Masses

Large and small enterprises have continually struggled with finding a way to manage the software risk inherent in their ever-increasing application portfolio. And now, in a year where companies such as NASDAQ, Knight Capital, American Airlines, and BATS have suffered costly and embarrassing IT failures, software risk is top of mind for every IT executive.
That’s why today we’re announcing an update to our flagship portfolio analysis solution, CAST Highlight, which expands the types of systems it can analyze to unlock the power of portfolio analysis for companies large and small. Its low-cost SaaS model makes it 20 times cheaper than traditional enterprise software, without the need for costly hardware or licenses, and less disruptive for users, ready to deploy in minutes, from any location without the need to transfer source code.

Some advice for the Fourth of July

Here’s a poster for you to celebrate the Fourth of July in the way only a mature development team can appreciate.

Feel free to download it, share it, or print it out and hang it around your office. Also feel free to annoy anyone who doesn’t understand the importance of insight and transparency in application development.

Who’s Minding the Store?

Before I could enjoy my Father’s Day brunch this past weekend, I found myself with a list of things to do around the house – cleaning out the garage, vacuuming the car, replacing our mailbox which “someone” in my family (not me) ran over. The latter of these tasks, of course, required that I go out and purchase some tools and supplies – a new post, new box, numbers for the box and a post digger – to get the job done.
My first stop in obtaining the necessary equipment, as always, was my local hardware store. I’m a huge proponent of buying things at local businesses rather than going out to the chain stores. I usually find the more local the store, the more helpful they are.
A similar theme, only from the “provider” point of view, is becoming pervasive among corporations when it comes to making applications available to their employees. Companies are “keeping it local” when it comes to making apps available. As InfoWorld’s app development guru, Paul Krill, points out:
“Companies developing their own custom applications, for example, do not want to make their intellectual property available in a commercial app store, so they set up their own.”
And who could blame them? With “Bring Your Own Device” (i.e., BYOD) one of the driving forces behind companies opening their own, proprietary app stores, organizations need to be certain that their customized apps do not wind up in the hands of those outside the company and they must be sure that the apps being downloaded by employees to access company files can be trusted.
With public app stores of today, that’s not always the case.
Buyer Beware
It’s little wonder companies want to keep their app stores close to the vest and their employees should actually be thankful for that move. If the news over the past 18 months about public app stores has shows us anything it’s that the quality of the available applications doesn’t always meet the highest standards for structural…and that’s being kind.
Take the Android app store for example. There are those who openly question if Google has any application software quality standards that need to be met before being offered in Android Market. Google would cite this laissez faire attitude as being part of its open source nature, but the old adage of programming – “Garbage in, garbage out” – should somehow apply to offering mobile apps in Android Market.
Even Apple, which posts a list of application standards for developers to use if they want to post an application to the App Store, has its issues with applications, but they see fewer of them. Why? Because their example of having a set of standards — and perhaps even a certification process —in place helps ensure structural quality and curbs the availability of malware in app stores.
Start at the Top
When it comes to application software quality, there is plenty of responsibility to be shared at each of level of mobile application distribution, and that’s a big reason why businesses are right in opening their own app stores for employees. Under their control, they can have oversight over the structural quality of the apps being offered and those who handle them – from those who develop the apps to those who administer the app store.
After all, responsibility for the structural quality of application software being offered rightly should begin at the top. The CIO or IT Director needs to establish a set of software quality standards for the apps being made available and then ensure any application that is offered meets those standards. This will help curb new issues and prevent vulnerabilities from older versions creeping into the new versions built on top of them.
Should companies fail to provide the necessary oversight for their app stores, they place their entire operation at risk because not taking responsibility for structural quality through a corporate app store is the same as nobody minding the store.

‘Gate Closings’ Before Gimmicks

With all of the security issues appearing in the press these days, I’m often reminded of a conversation I had with John Kilroy, the former CIO at Cape Cod Hospital. At the time I was doing media relations work for a company in the Health Care IT industry and was working with Kilroy, who has been retired for the last five years, on an article for one of the publications that covers that space.
The big issue back then was the Health Insurance Portability and Accountability Act, better known as HIPAA. The underlying security issues behind HIPAA are very similar to those being faced by every organization that keeps its data online today – keeping that information from being exposed to unauthorized persons.
Back then, everyone from Congress to the HCIT vendors to hospitals were looking for a technology fix to the problem. At the time, electronic medical records were in their relative infancy and were bashed by some as being a security risk…although those in the HCIT field would argue that keeping patient files behind layers of firewalls and encryption is far more secure than keeping them in a physical rack on the desk of woefully undermanned nursing stations.
The article Kilroy and I were writing was about making electronic health systems ready for HIPAA. Something Kilroy said during our initial conversation about the article, however, still stand out to this day. He said, “Even more than making sure information doesn’t leak out of electronic health systems, because they’re usually secure, is getting our staff and the patients themselves not to reveal information in public places like the hallway and elevator.”
This conversation was definitely top of mind when I read a brief article penned for InformationWeek by Jonathan Feldman, director of IT Services for the city of Asheville, North Carolina, about how the training of personnel was far more important than the technology being used.
Kowtowing to Security Needs
Feldman laments in his opening paragraph:
IT pros tend to focus solely on technology to solve endpoint security problems. After all, if malicious software is the poison, it’s logical to look to signatures, heuristics, and cutting-edge detection for the antidote. But that’s a mistake. Human vulnerabilities–ignorance, inattention, gullibility–are just as exploitable as software vulnerabilities, if not more so.
Feldman follows this by offering a checklist of exercises he believes companies should conduct with their employees to ensure they understand not only the importance of keeping proprietary information proprietary, but also how to detect when they are being plied for information that should not get out. These steps involve:

Conducting a phishing drill
Hitting Employees with In-Your-Face Propaganda
Letting employees know there’s something in it for them
Make it fun and personal through group meetings to discuss the issue
Being supportive of employees about their due-diligence efforts
Get the execs to talk to employees about how important their diligence is

While Feldman’s methods are a bit “gimmicky,” I do not disagree that getting employees on board and practicing less risky behavior in terms of data leakage is important. Teaching employees how to detect phishing emails and how not to be duped into revealing passcodes is not only important to an organization, it is vital to its survival. However, saying that the human vulnerabilities are more important than the technological ones may be overlooking one fact – that humans are fallable.
Human fallibility means that no matter how much teaching about security measures a company conducts, one day something will slip through the cracks. If the structural quality of the applications targeted do not receive equal attention, that slip could lead to a costly data breach – and it only takes one breach to cost a company millions of dollars or worse, its reputation.
Moo-ving in a Secure Direction
One thing most security breaches have in common is that they were the result of some structural quality defect in an existing application that served as a point of vulnerability. If that vulnerability doesn’t exist, then it stands to reason that attacks that slip through the “human” layer of defense will likely be thwarted. But just how can vulnerabilities in application software be detected?
Evaluating an application for its structural quality defects is critical since these defects are difficult to detect through standard testing; yet these are the defects most likely to cause security breaches by unauthorized users.
A company that truly wants to address a security breach should first analyze the applications in its IT system to find which of them has issues with structural quality that could have been the breaching point (or points). Most companies historically have avoided doing this because all they had available to them was either manual testing – which is grossly inefficient in terms of accuracy, cost and time investment – or comprehensive analysis platforms that only large enterprises could afford.
Today, however, there are automated analysis and measurement tools on the market offered via Software as a Service (SaaS), which makes it cost-effective and much easier to find application vulnerabilities in an IT system. In fact, with these SaaS versions of automated analysis and measurement on the market, finding vulnerabilities should probably be bumped in priority to BEFORE a breach happens.
After all, failing to find vulnerabilities before breaches is akin to closing the gates after all the cows have gone.