What’s different about mobile apps?

August 27, 2012

The adoption of smart phones across a wide cross-section of the world has opened up a new arena for business application software: mobility.  This article outlines what’s different about mobile “apps” – and what remains the same as desktop PC software.

Small screen

In the world of media (such as movies), the big screen is in a movie theater, the small screen is a television set, the smaller screen is on a PC, now the tiny screen is on your mobile phone.  While you may be able to watch a movie on a mobile phone, you can’t expect to interact with business software the same way on this tiny screen as you do on a PC.

On the other hand, you’re not always sitting in front of your PC.  But your mobile phone is nearly always at hand, so this makes it attractive as an “always on” device that you can use for interacting with your business.

Since the introduction of the Apple iPhone, the underlying operating system software of the smartphone has had nearly all of the capabilities of a PC operating system, with one exception:  only one app can run at a time (up to now).

Aren’t mobile apps and PC applications the same?

Some characteristics of apps are the same as for PC.  For example, apps must be developed to match the specific operating system found in the smartphone.  This means that a iPhone app has to be deliberately designed for the Apple IOS system, an app for a Samsung phone has to be designed for the Android system, and so on for Nokia and Blackberry apps.

The people who develop apps have to use a development environment (a bunch of software tools) specific to the target OS, or else use an environment that is “cross-platform,”  so that their resulting app is adapted to the target OS.  There are many of these cross-platform tools.  If you’re interested in them, see http://en.wikipedia.org/wiki/Mobile_application_development .

Other restrictions

Each target operating system may have other restrictions, such as the requirement that all apps for the iPhone be reviewed and approved by Apple.  This makes the job of the developer harder if he is trying to make an app that runs on any phone.

A mobile app is software that runs on the phone and uses the underlying operating system to perform certain functions, such as interacting with the user and communicating with a website or the telephone system.  Some of the functions available in a smartphone are unique to the mobile environment, such as being able to find out where the phone is right now from the GPS.

Browser-based interactions

Just as with a PC-based user, one way to implement business functions is to use a browser to access a server offering the functions.  In fact, a server can implement both PC and mobile versions of its user interface in order to offer the same – or nearly the same – features to both PC-based and smartphone-based users.

One of the current developments in browsers is the HTML5 language, which allows a single software package to offer adaptable results that can make mobile/PC apps easier to move around to different phones and/or PCs.

Of course the designer of the user interaction has to be aware of the size of the screen.

What about security?

Whether an app is PC based or smartphone based, security is still an issue.  And moving the functions into a browser-based app in a server does not take care of all the security issues, either.  We’ll take up the question of security in a future blog entry.

 

For more information about app development, here’s a link to one of the commercial companies that do mobile application development.

Filed Under: Painless IT Tagged With: , , , , , , , ,

Why isn’t software more secure?

August 13, 2012

What makes software insecure?

Software is often insecure because it is complex, abstract and not completely understood even by the people who create it.  A software specialist who designs a human interaction module may not know much about the database software that the module depends on, for example.

In addition, software runs in a hardware environment (the computer system) that is not completely known by the creator of the software.  For example, when a software package is designed to run in a Microsoft Windows system, the hardware may have been manufactured by any of a dozen companies, each of which has its own detailed hardware environment (including things like BIOS, memory, storage, and input/output subsystems).

And the software itself has to keep changing to keep up with user expectations.  Software that doesn’t get updated gets stale.  [See more about this in my previous blog: stable or static]:

What vulnerabilities are there in software?

Software is vulnerable to many possible conditions that it may not be prepared for.  For example, unexpected inputs can lead to errors: if the software is expecting a number and it gets a value that is outside of reasonable bounds, it may have unpredictable consequences.

In addition, computer hardware can have exception conditions occur during instruction execution, such as dividing by zero.  These exceptions must be anticipated by the software, or else the program can simply terminate without finishing its work.

For example, one of the popular ways for hackers to break into computer systems is to create a “buffer overflow condition.”  If the software does not anticipate this condition, the computer can execute code that the hacker put into a data structure in advance, causing the computer to come under the control of the hacker.

Why are they always discovering new holes & vulnerabilities in our software and systems?  Doesn’t testing take care of these problems?

Proper testing can reduce insecurities and other bugs.  Often, software development organizations simply don’t use the best tools for testing.  But testing every possible case is impossible.  Testing has to be done using human judgment to decide the testing strategy.

[For an excellent exposition on this subject, see Gerald Weinberg’s book, Perfect Software]

Often the failure to do adequate testing is the fault of management.  When a software development project is behind schedule, the temptation to short-change the testing is very high, because testing is usually tacked on to the end of the development cycle.

[For more on this, see my previous blog: good software]

How else is software insecure?

Most software does not run in a vacuum.  Often it is interacting with a human operator.  When a program and a human are interacting, there are plenty of opportunities for misunderstandings.  For example, error messages may be confusing, or the human may take the wrong action in response to a warning message.

The people who make it their business to take advantage of software vulnerabilities – call them hackers or attackers – are becoming more sophisticated.  They may be after money or industrial secrets, and they often know a lot about the system and the person who is interacting with the system.

A whole class of attack, called spear-phishing, is based on deliberately showing misleading information to the human, such as an email that appears to come from the person’s boss.  Vulnerability to these attacks occurs both in the system (email delivery without validation) and in the person (accepting what appears at face value).

What’s an enterprise to do about insecure software?

As a first step, make sure that you have engaged security specialists – people who have studied and are expert in attacks and in security countermeasures.  The specialists should include “white hat” testers – people who deliberately try to break into your own systems in order to demonstrate vulnerabilities.

You should also ask questions of your project managers about tradeoffs being made between testing and quality.   You must recognize that when you choose to emphasize schedule, you often invite lower quality and therefore higher vulnerability.

Never assume that software is of high quality – and therefore invulnerable – until you have seen it demonstrated in actual use by real users.  And even then, expect to find vulnerabilities regularly, and be ready to fix them.

 

TO SUBSCRIBE FREE: https://johnlevyconsulting.com/blog

Just complete the simple form. Takes about 10 seconds. And you’ll also get a free copy of my report, “9 Mistakes That Lead to IT Project Failure.”

John Levy — Turn Around IT
      Helping business get full value from IT

https://johnlevyconsulting.com

PO Box 1419, Point Reyes Station, CA 94956    415 663-1818

Filed Under: Painless IT Tagged With: , , , , , , , , , , , , , ,

Is your software stable or static?

July 10, 2012

In most professions, it’s good to have stability in the things you work with.  With software, stability is good, but often we confuse static with stable.  They are not the same.

Static software decays and becomes useless.

In a previous article, Why does it cost so much to maintain systems? I explained how software updates are critical to keep it alive:

Software by its nature is constantly evolving.  Not only do users ask for new and modified features, but the systems on which the software runs keep changing, so the software has to be modified to fit new environments.  These factors guarantee that updates have to be released several times a year to keep things current.

Here are some indicators that software is stable:

• Updates are regular but not urgent

• The list of bug fixes in each release is not excessively long

• You don’t experience crashes & freezes on the system

• The software “plays well with others” – there are no negative interactions with other software packages

• It scales up smoothly – there are no abrupt limits as the data size or workload increases, only a gradual slowing of response time

• The vendor’s support is consistently accessible and useful

On the other hand, static software is an entirely different thing.  If software is static it means that there are no updates, changes or evolutionary steps being taken to keep the software current.  As a result, some or all of the following will happen:

• The software will not run in new environments, such as latest release of the operating system

• The files being used with the software do not evolve with changing data formats, file systems and storage media.  Compatibility is lost with other software that begin using new data and file formats.  Old backup copies of data may not be readable on new storage devices.

• The software will not communicate using new network interfaces.  When it does communicate, it may be using old protocols that slow down the speed of transfers and do not use new features available in the network.

• The software may not be able to interact with cloud-based applications and databases that have been added since the software was released.

Stable software requires constant attention by the people who are maintaining it.  They should be in regular dialogue with the users of the software, have a list of issues they are investigating and correcting, and be using a set of maintenance tools that allow consistent and stable releases.

Strive to have stable, but not static software. 

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,

Why is software maintenance so expensive?

June 12, 2012

When we purchase a piece of software – even as a service – we tend to think that the major expense is finished with the purchase price.  But it’s not true.  Whether you buy, build your own, or rent software, it always costs more in ongoing expenses than the initial price.  Why?

Developing software is an expensive proposition.  Not only do the people cost a lot, but they use expensive tools, and they always seem to need more time than was estimated at the front end of the project.  So we should not be surprised that software sells for a lot of money, even when the vendor is selling a lot of copies.

But why does maintaining that software cost so much?  Here are some of the reasons:

Software by its nature is constantly evolving.  Not only do users ask for new and modified features, but the systems on which the software runs keep changing, so the software has to be modified to fit new environments.  These factors guarantee that updates have to be released several times a year to keep things current.

Just because you bought the software doesn’t mean you – or the rest of your staff – know how to use it well.  So you need people to study up on the software’s functions and then teach others how to make the best use of it.  If you don’t, you won’t realize the full benefit that the software offers.

The worst thing that can happen to a software user is to learn that the vendor has gone out of business.  So you want the vendor to do what it takes to keep making those updates and upgrades available.  This means that the vendor also has to keep a stable of specialists assigned to the software product, even if it is no longer the mainstay of the vendor’s business.  And those specialists have to aware of how customers are using the product, and what kind of support they need.  So you’re willing to pay for that support, if the product is of great value to you.

When things go wrong, you need someone to call.  If you’re a big enterprise and the software is integral to your operations, you’ll want that someone to be nearby – and on your own payroll.  Otherwise, the person will not feel the urgency that you do when there’s a failure.  So you, too, have to maintain a staff of specialists who keep up to date with the software’s features and failings, and know how to work around any problem that comes up.

Furthermore, when something fails, you typically don’t know whether it was caused by a software bug in the application, a system failure or something gone haywire in the infrastructure (such as the network).  So you need IT specialists who can diagnose failures and then pursue the solutions no matter where the failure originated.

Can you avoid all of these expenses by using software in the cloud?  Not so fast.  You may save money by renting software that runs in the cloud, but you have to be ready to accept a standardized version of the software that everyone else is running, too.  Or you’ll have to pay extra for customization, which leads you right back into the ongoing costs of maintenance.

You’ll also have to endure the changes that come when the cloud-based software vendor decides to upgrade the system – on the vendor’s timetable, not yours.  So maybe you need those specialists in IT after all?  And the cost savings of the cloud are not completely one-sided.

Filed Under: Painless IT Tagged With: , , , , , , , ,

Why is it so hard to get good software?

May 29, 2012

Once we get over our wonder at the broad capabilities of software running on modern computers and devices, we begin to ask why so much of the software we use is of questionable quality.  Between vulnerabilities to malware and constant updates to correct problems, it seems that software is never stable and reliable.  Why?

Software is abstract, invisible and runs at very high speed.  This combination of features makes developing software the domain of a special kind of person who can deal with the abstractions and with the incredibly fine detail of software creation.  Managing a group of such people also requires a special kind of talent as well, because there are tradeoffs to be made between getting new features added and stabilizing the functions that are already built-in.

Usually, the pressures of commercial software development lead software marketers to place much more emphasis on new features than on stability, because features are what differentiate one software product from another.  However, the long-term stability of a product also contributes a lot to the product’s reputation.

Software testing is the usual way to verify proper functioning before shipment.  But since software development routinely takes longer than anticipated, it is the testing that gets short shrift in many cases.  The result is premature delivery of software that is not yet ready for commercial use.

A 2002 study commissioned by the National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually. The same study found that more than a third of that cost — about $22.2 billion — could be eliminated by improving testing.     http://on.msnbc.com/Kae58w

In addition, the operating context of software is constantly changing.  As operating system upgrades are released, the software that works under that operating system often must be adapted to the upgrades.  This means that a lot of the work of keeping a software package current goes to merely maintain the capabilities that were already built.

Users continue to ask for new features.  And marketers want the software to be useful in more contexts – such as making an app useful on an Android phone in addition to an iPhone.  These demands guarantee that a software package will always have an endless backlog of potential changes in the “to-do” list.

As more contexts are supported and more features are added, the software inevitably becomes more complex.  And complexity multiplies the difficulty of testing, and also makes each change to the software riskier.  The more interactions that are possible with each part of the code, the more possibilities there are for mistakes.

What can I do to help make software better?

Purchasers of software don’t have very high expectations, because the track record of the software industry does not set a very high bar.  If users demanded better software and rejected poor software, software vendors would provide better packages – or go out of business.  Why don’t we demand better software?

One reason is that it is hard to switch.  Once we have adopted a piece of software for some function, we tend to stay with it.  First of all, it’s what we are familiar with.  This “makes us rather bear those ills we have than fly to others that we know not of.” [Shakespeare – Hamlet]  The cost of learning a new system is high, and we tend to stay with what is familiar, even if it is painful to use.

Second, the vendors of software don’t often make it easy for us to switch to another vendor.  Try taking an Access database and “porting” it to FileMaker Pro.  The conversion process is a barrier that most of us are unwilling to undertake.  In addition, there may be many people who need to be trained in the new system if we switch.  That adds to the cost.

In the future, we should look at the cost of switching before committing to a software vendor or cloud system.  The more “open” the system, the better for us in the long term.

And we should always insist on demonstrably high quality in software.  Keep this in mind the next time you’re making a purchase decision.

 

Filed Under: Painless IT Tagged With: , , , , , , , , , , , ,

It’s actually easier to do the right thing

March 26, 2012

The right thing is to plan, organize and execute with long-term results in mind.  But nearly every manager is so driven by short-term metrics that they fail to account for longer-term effects of their decisions and actions.  As a result, they accomplish less for themselves and for their organizations, making them less effective and less competitive.

Here are three ways to incorporate longer-term thinking:

1. People working for you know when they’re being put at a disadvantage due to short-term thinking.  For example, if you won’t spend the capital needed to buy the right tools, they’ll keep working, but they’ll resent both the inefficiency of the work and the lack of regard it shows for them as workers.

People will find ways to correct problems and to self-organize to be more efficient if you will only give the room to operate.  This includes trusting them to find the best way to organize and giving them enough budget to execute the plan.    Your main contribution after that is to give them enough of the bigger picture so they know how their work fits in with your objectives.

2. If you’re committed to personal growth, then you need to track your effectiveness over a longer term.  Your monthly or quarterly objectives are the table stakes in this game.  Cranking out regular results will guard your job, but it won’t make you ready for a larger role unless you include a vision of what’s possible in the longer term

If you want to be seen as an emerging leader, then you have to champion longer-term growth and improvement.  To do that, you’ll need to solicit feedback and actually listen to it.  And you’ll need ways to identify short-term objectives that are actually causing damage to longer-term results.

For example, a client company refused for years to convert to better programming language tools because changing tools would make the first project to use them take longer.  As a result, they went for years at a disadvantage compared to their competitors.   Eventually, they changed – when they merged with a competitor that was already using the tools.

3. In some areas, such as product development, experimentation is essential.  You may think that Engineering is a deductive, forward-only process; but in fact a lot of development involves eliminating the unworkable by trying it out.

Once you realize that experimentation is part of the process, you stop regarding abandoned directions as a waste of time and resources.  In fact, experiments lead to better decisions and stronger platforms on which good products are based. Since the result of having stronger platforms is not visible until the next product, you could harm your product line significantly by insisting on maximum-speed implementation.

The alternative to backtracking after an experiment is to fall off a cliff – with failure of the process.  It’s better to insist on high-quality, incremental progress.  And how do you know you are seeing incremental progress?  You have to have a longer-term vision and plan to measure it against.

Once you have the vision and the plan, it’s actually easier to do the right thing.

 

How are you keeping longer-term results in mind?  Post your comments below.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , ,