How to untangle code: Remove the tricks

We all have our specialties. Mine is the un-tangling of code. That is, I can re-factor messy code to make it readable (and therefore maintainable).

The process is sometimes complex and sometimes tedious. I have found (discovered?, identified?) a set of practices that allow me to untangle code. As practices, they are imprecise and subject to judgement. Yet they can be useful.

The first practice is to get rid of the tricks. "Tricks" are the neat little features of the language.

In C++, two common types of tricks are pointers and preprocessor macros. (And sometimes they are combined.)

Pointers are to be avoided because they can often cause unintended operations. In C, one must use pointers; in C++ they are to be used only when necessary. One can pass a reference to an object instead of a pointer (or better yet, a reference to a const object). The reference is bound to an object and cannot be changed; a pointer, on the other hand, can be changed to point to something else (if you are very disciplined that something else will be another instance of the same class).

We use pointers in C (and in early C++) to manage elements in a data structure such as a list or a tree. While we can use references, it is better to use members of the C++ STL (or the BOOST library). These containers handle memory allocation and de-allocation. I have successfully untangled programs and eliminated all "new" and "delete" calls from the code.

The other common trick of C++ is the preprocessor. The preprocessor macros are powerful constructs that let one perform all sorts of mischief including changing function names, language keywords, and constant values. Simple macro definitions such as

#define PI 3.1415

can be written in Java or C# (or even C++) as

const int PI = 3.1415;

so one does not really need the preprocessor for those defintions.

More sophisticated macros such as

#define array_value(x, y) { if (y < 100) x[y]; else x[0]; }

let you check the bounds of an array, but the STL std::vector<> container performs this checking for you.

The preprocessor also lets one construct function calls at compile time:

#define call_func(x, y, a1, a2) func_##x##y(a1, a2)

to convert this code

call_func(stats, avg, v1, v2);

to this

func_statsavg(v1, v2);

Mind you, the source code contains only the unconverted line, never the converted line. Your debugger does not know about the post-processed line either. In a sense, #define macros are lies that we programmers tell ourselves.

Worse, they are specific to C++ (and possibly C, depending on their use of object-oriented notations). When you write code that invokes the C++ preprocessor, you lock the code into that language. Java, C#, and later languages do not have the preprocessor (or anything like it).

So when un-tangling code (sometimes with the objective of moving code to another language), one of the first things I do is get rid of the tricks.

I thought I knew which languages were popular

An item on Hacker News lead me to a blog post by the folks at Codacy. The topic was "code reviews" and they specifically talked about coding style. The people at Codacy were kind enough to provide links to style guidelines for several languages.

I expected the usual suspects: C, C++, Java, C# and perhaps a few others.

Here's the list they presented:

• Ruby
• Javascript
• Python
• PHP

My list was based on the "business biggies", the languages that are typically used by large businesses to "get the job done". Codacy is in business too, so they are marketing their product to people who can benefit from their offerings. In other words, this is not an open-source, give-it-away-free situation.

Yet they list languages which are not on my "usual suspects" list. All of their languages are not on my list. And none of my languages are on their list. The two lists are mutually exclusive.

The languages that they do list, I must admit, are popular and mature. Individuals and companies use them to "get the job done". Codacy thinks that they can operate their business by focussing on these languages. (Perhaps they have plans to expand to other languages. But even starting with this subset tells us something about their thought process.)

I'm revising my ideas on the languages that businesses use. I'm keeping the existing entries and adding Codacy's. In the future, I will consider more than just C, C++, Java, and C#.

After Big Data comes Big Computing

The history of computing is a history of tinkering and revision. We excel at developing techniques to handle new challenges.

Consider the history of programming:

Tabulating machines

• plug-boards with wires

Von Neumann architecture (mainframes)

• machine language
• assembly language
• compilers (FORTRAN and COBOL)
• interpreters (BASIC) and timeshare systems

The PC revolution (the IBM PC)

• assembly language
• Microsoft BASIC

The Windows age

• Object-oriented programming
• Event-driven programming
• Visual Basic

Virtual machines

• UCSD p-System
• Java and the JVM

Dynamic languages

• Perl
• Python
• Ruby
• Javascript

This (severely abridged) list of hardware and programming styles shows how we change our technology. Our progress is not a smooth advance from one level to the present, but a series of jumps, some of them quite large. It was a large jump from plug-boards to memory-resident programs. It was another large jump to an assembler. One can argue that later jumps were larger or smaller, but those arguments are not important to the basic idea.

Notice that we do not know where things are going. We do not see the entire chain up front. In the 1950s, we did not know that we would end up here (in 2014) with dynamic languages and cloud computing. Often we cannot see the next step until it is upon us and only the best of visionaries can see past it.

Big Data is such a jump, enabled by cheap storage and cloud computing. That change in technology is upon us.

Big Data is the acquisition and storage (and use) of large quantities of data. Not just "lots of data" but mind-boggling quantities of data. Data that makes our current "very large" databases look small and puny. Data that contains not only financial transactions but server logs, e-mails, security videos, medical records, and sensor readings from just about any kind of device. (The sensor readings may be from building sensors for temperature, from vehicles for position and speed and engine performance, from packages in transit, from assembly lines, from gardens and parks for temperature and humidity, ... the list is endless.)

But what happens once we acquire and store these mind-boggling heaps of data?

The obvious solution is to do something with it. And we are doing something with it; we use tools like Hadoop to process and analyze and visualize it.

I think Hadoop (and its brethren) are a good start. We're at the dawn of the "Big Data Age", and we don't really know what we want -- in terms of analyses and tools. We have some tools, and they seem okay.

But this is just the dawn of the "Big Data Age". I think we will develop new techniques and tools to analyze our data. And, I suspect those tools and techniques will require lots of computation. So much computation that someone will coin the term "Big Computing" to represent the use of mind-boggling amounts of computing power.

Big Computing seems a natural follow-on to Big Data. And just as we have developed languages to handle new programming challenges, we will develop new languages for Big Computing.

We have two hints for programming in the era of Big Computing. One hint is cloud computing, with its ability to scale up as we need more power. We've already seen that programs for the cloud have a different organization than "classic" programs. Cloud programs use small modules connected by message queues. The modules hold no state, which allows the system to route transactions to any available module.

The other hint is at the small end of the computing world, at the chip level. Here we see advances in processor design: more cores, more caching, more processing. The GreenArrays GA144 is a chip that contains 144 computers -- not cores, but computers. This is another contender for Big Computing.

I'm not sure what "Big Computing" and its programming will look like, but I am confident that they will be interesting!

The Mobile Evolution is different from the PC Revolution

When PCs entered the scene, it was a revolution. The entry of mobile devices (smartphones and tablets) is less revolution and more evolution.

What is the difference? Exclusive applications.

When PCs entered the market, they shared some applications with minicomputers and mainframes (assemblers, compilers, and text editors, mostly) but a large percentage of applications were unique to PCs. Word processors, spreadsheets, and games were the popular applications, and none of them were from mainframes.

Mobile applications, for the most part, are extensions of existing PC and web applications. Twitter, Facebook, even Google Maps all live on the web and in the mobile world.

There are some apps that are (or were) mobile-only. "Angry Birds" was first released for the iPhone and later moved to other platforms. FourSquare is a mobile-only app, given its "check in" function.

But the number of mobile-only apps is small, compared to the total. This is quite different from the PC revolution, which saw thousands of PC-specific applications and a small number of mainframe "crossover" applications.

The PC world was filled with new applications, and new types of applications. That's why it was a revolution. The mobile world -- so far -- is filled with extensions to web applications. That's why the mobile world is an evolution.

Legacy code isn't code -- its a lack of tests

We have all heard of legacy code. Some of use have had the (mis)fortune to work on it. But where does it come from? How is it created?

If legacy code is nothing more than "really old code", then when does normal code become legacy code? How old does code have to be to earn the designation "legacy"?

I've worked on a number of projects. The projects used different programming languages (C, Visual Basic, C++, Java, C#, Perl). They had different team sizes. They were at different companies with different management styles. Some projects had old code but it wasn't legacy code. Some projects created new code that was legacy code from the first day.

Legacy code is not merely old code. Legacy code is code that few (if any) team members want to modify or enhance. It is code that has a reputation, code that contains risk. It is hard to maintain and easy to break.

Legacy code is code without tests.

With a set of tests -- a comprehensive set of tests -- one can change code and be sure that it still works. That is a powerful position. With tests to verify the operation of the code, programmers can refactor code and simplify it, knowing that mistakes will be caught.

Without tests, programmers limit their changes to the bare minimum. Changes are small, surgical operations that adjust the smallest number of lines of code. The objective is not to improve the code, not to make it readable or more reliable, but to avoid breaking something.

Changes to code with tests also strive to avoid breaking things, but the programmer doesn't need the paranoia-like fear of changes. The tests verify the code, and frequent testing identifies errors quickly. The programmer can focus on improvements to the code.

Don't ask the question "is our code legacy code" -- ask the question "do we have comprehensive tests".

Installing Windows 8 is not always easy

I think Microsoft is missing a useful tool for would-be Windows 8 users.

The tool I am thinking about is a compatibility checker for PC hardware. I have an old PC and I am considering Windows 8 for it. My big question is: Will Windows 8 run on it?

I would prefer an answer to that question before committing to the purchase of Windows 8.

The Microsoft web site is very good about listing the requirements for running Windows 8. They specify a processor speed, memory, and disk space. Those are easy (for me) to verify. Microsoft also mandates that the graphics card be a "Microsoft DirectX 9 graphics device". That requirement is not so easy to verify.

The PC in question is a vintage Dell Optiplex GX-280 desktop PC. I'm pretty sure that it predates DirectX 9.

Given the difficulties in verifying hardware, I would think that a utility would be available. Something small and simple, that would run and say "yes" or "no". Yet I find no such utility.

Now, there are utilities that you can run on existing Windows systems and these utilities check the hardware and your current applications. They assume, however, that you are already running a version of Windows.

Did I mention that my PC is *not* running Windows? Did I mention that my PC is running a variant of Ubuntu Linux?

That means that I cannot run the Microsoft-supplied, Windows-only, compatibility checker utility.

From what I can see, my only option is to attempt to install Windows 8, use the activation code (it's the first thing that the install program requires), and hope that Windows finds my system acceptable. That's a risk (in money and time) I would rather not take.

This approach is very different from most Linux distros, which allow one to run Linux in "live" mode from the CD (and not touching your hard drive) to verify compatibility.

I don't know that Microsoft needs a "run off the CD" mode for Windows. The option to verify hardware would be nice -- perhaps as the first step of the install, and before the activation code. Such an option would let me confirm my installation before committing.

If not part of the install program, perhaps a stand-alone utility that runs under Linux. (Perhaps even an open source utility!) Something one could build with gcc and run from the command line. It doesn't have to be fancy -- since anyone using it would be a Linux user with sysadmin experience. (If you're installing a new operating system, you're a sysadmin.)

Perhaps Microsoft considered this capability, and decided against it. Such capability does add to the complexity of the setup disk. As a practical matter, most PCs will be running Windows, and configurations such as mine are a very small minority. I could easily see Microsoft choosing to invest the effort in other directions.

Yet I cannot help but think that in today's market Windows must compete against Mac OS and Linux. Tools to assist people converting from non-Windows to Windows might be a good idea.

The great puzzle of Microsoft Office

What will Microsoft do with Office? Or, what should Microsoft do with Office?

Microsoft built an empire with Office. Office was the most powerful word processor and spreadsheet package. It used proprietary formats. It read files from other word processors and spreadsheets but did not write to those formats, making the trip for data one-way: into Microsoft Office. Through marketing, fierce competition, and the network effect, Microsoft convinced most businesses and most home users to use (and buy) Microsoft Office.

Those were the days.

The world is changing.

Large businesses still use Windows for their desktop environment. Small businesses, especially technology start-ups, are using Mac OS or Linux.

Large businesses still use Microsoft Office. Small businesses are looking at LibreOffice (an open source desktop package with word processing and spreadsheets) or Google Apps (an on-line office package with word processing, spreadsheets, e-mail, calendaring, and other things).

The tablet world is dominated by iOS (on iPads) and Android (on just about everything else). Windows holds a tiny share. The same goes for smart phones.

These are the pieces of the great puzzle that Microsoft must solve. What is a software giant to do?

First, some observations.

Microsoft is the latecomer Microsoft is late to the market, but they have been in this position before and succeeded. They were late with C#/.NET after Java. They were late with Internet Explorer after Netscape Navigator. They were late with spreadsheets after Lotus 1-2-3. They were late with word processors after Wordstar and WordPerfect. They were late with databases after dBase and R:Base. Being a latecomer has not doomed Microsoft yet.

New hardware platforms Microsoft must live (and compete) in a world beyond the PC. Phones and tablets must be part of the solution. Tablets and phones are a very different arena for software design, due to the size of the screen, the touch interface, and intermittent connectivity. Any product on the tablet or phone is a different creature than it's PC counterpart.

Multiple software platforms Microsoft must live (and compete) in a fractured world of software, with multiple operating systems (some not of Microsoft's making or control). Offerings from Microsoft must work with iOS and Android as well as Windows.

The desktop software model doesn't work on mobile devices Microsoft's past technique of selling premium software and obtaining market share through marketing won't work on the mobile platform.

Giving these conditions, Microsoft needs a new approach. Here are some ideas:

Sell services, not software Microsoft will not focus on selling copies of Office for the mobile world. Instead, it will focus on subscribers to its services. The mobile versions of Word and Excel and Outlook will be offered at low prices -- perhaps at no cost -- but they will be useless without the service.

Cloud storage, not local files Microsoft Office will store data in the cloud (Microsoft's cloud).

Not documents and workbooks, but pieces assembled Instead of entire documents and complete spreadsheets, Microsoft services will stitch together fragments of documents and spreadsheets. Think of it as an advanced form of OLE. (Remember OLE and our excitement at embedding a spreadsheet in a document?)

Versioning and tracked changes Microsoft's cloud will keep track of the versions of each document (or document fragment), allowing us to see changes over time and the notes for each change.

Access control (for enterprise users) With all of these fragments floating in the cloud, enterprise users (businesses and their support teams) will want to control access by users.

Promotion and publication (also for enterprise) Users will be able to publish data to other users. Users will also be able to work on new versions of data, reviewing it with other members of their team, revising it, and eventually marking it as "available to everyone". Or maybe "available to selected users".

The idea of Office as a service seems a natural fit for mobile devices. Notice this this vision does not demand Windows tablets -- one can use it with iPads and Android devices. I expect Microsoft to move in this direction.