Category: software

When is it bad idea to have modularity in software?

Modularity is the most successful software engineering practice ever. Unlike other practices, it is practically never abused.
One day I was asked when is it bad idea to modularize software. Of course, for every good thing there are always pathological or contrived circumstances, in which it turns out to be a bad idea. Software modularity is no exception to this.

Algorithms

To be able to present and understand complicated algorithms, they need to be modularized. Then, when wishing to optimize such an algorithm, one typically confines himself to local optimizations, rather than to global optimizations.
When global optimizations are needed, the algorithm developer has to forsake modularity, and the resulting algorithm becomes very big and difficult to comprehend.

Source code level

Due to the way the human brain works, modularity is always good in source code level. However, it needs language support, such as support for macros and in-line functions to allow compilation into efficient machine code.
On the other hand, one can expect the software development environment to have source code pre-processing tools, which work around any language support deficiencies. Nowadays, it is not a big deal, unless one works for a mentally retarded software development operation.

Machine code level

In machine code level, software modularity means usage of DLLs, inter-module interfaces, plug-ins, etc.
This kind of modularity can be bad, if a module interface overhead directly affects a system bottleneck. A system bottleneck could be CPU time, memory consumption, I/O, database accesses, network latency/throughput, etc.
A good system design implements machine language level modularity when the overhead is not critical to performance; and optimizes the interfaces away where system bottlenecks occur.

16th Linux Day

Today, 16 years ago, Linus Torvalds released version 0.0.1 of the Linux kernel.

This is an occasion to reminisce how I began to use Linux, and how I subsequently switched to 100% Linux usage at home.

I started using Linux about 13 years ago. For me, the killer application was Brian Marick’s GCT – a C Coverage Tool. At the time I worked as freelancer in the area of medical software testing, and needed a way to assess code coverage of my tests.

After the failure of an attempt to port GCT over to the world of 16-bit computing in MS-DOS, I found out about Linux. I soon found Harvey Stein, who had Linux (the Linux-IL mailing list, whose Patron Saint was Harvey Stein, started operating at about the same time – and this is no coincidence!). Mr. Stein let me come to his office and copy from him about 40 5.25″ diskettes of the Slackware distribution.

I copied the diskettes and installed Linux in an empty partition in my 5MB AT386 PC. Soon afterwards, I got GCT working!

The first Kernel version, which I installed, was 1.0.8. Soon after installation, I upgraded to Kernel version 1.1.13.

The old AT386 PC is still operational, and is bootable into either MS-DOS or Linux (Kernel version 1.2.13).

Additional links:

One day I acquired a new PC, but used MS-Windows 95 on it. I used the old AT386 for E-mail and surfing, and the new PC – for software development. At the time I developed software, rather than testing it. Few upgrades later, I installed RedHat 5.1 on the new PC, and it became dual-boot.

Subsequent years saw me switch to RedHat 7.2, 8.0, and then to Debian. I also had MS-Windows 2000 (in another hard disk).

One day, the PC’s motherboard died and I was forced to upgrade to a new one, with clock frequency beyond 1GHz. The MS-Windows 95 ceased to operate, and MS-Windows 2000 was problematic. Linux booted on the new motherboard without having to make any modifications or installations whatsoever. This was when I abandoned MS-Windows altogether and switched to Linux fulltime.

Over the years, I did not need to rebuild my PC’s Linux hard disk due to malware. I did rebuild it due to switching to new versions of RedHat and then Debian. As a proof, I present the fact that my ICQ number is still 8-digit long.

A Proven Free Software Business Model

Companies like MySQL, RedHat and Zend (trademarks belong to their owners) make a lot of money from Free Software. This indicates that they have a Free Software business model, which really works. This is interesting, because when people discuss Free Software business models, usually there is a lot of handwaving. There are assertions, which are left unsubstantiated. However, the above companies found a business model, which really works. This business model goes as follows.

  1. If you are hobbyist and make no money from our software, then our software is free for you.
  2. If you make little money from our software, then our software is free for you, too.
  3. If you make a lot of money from our software, then you pay for using our software.

The above model works, when it works, due to the following reasoning.

  1. If you do not make money from our software, then you do not have the money to pay us anyway. If we demand money from you, you just stop using our software and switch to another hobby, in which our software is not needed. We prefer that you use our software, even if we get no money from you, due to the same reason Microsoft tolerated software piracy as a means for conquering a market for their software. We want you to find more uses for our software. We want you to debug it. We want you to contribute improvements to our software. On the other hand, you cannot make more money by having our software optimized for your environment, so you do not need support from us.
  2. If you make little money from using our software, then we would like to have a cut from your profits, as well. However, we cannot justify the costs involved in collecting from you. For this, we need to sign contracts, install licensing infrastructure, enforce licenses, incur badwill, and even support you if our licensing mechanism causes you problems. Therefore we would not collect money from you. However, we win from your using our software due to the same reasons as we would win from people who make no profit from using our software. There is also the chance that one day you will become a big business; or even come to make our software a critical part of your business infrastructure. Then the following applies.
  3. If you make a lot of money from using our software, then you have an interest in having the software work all the time. You want any bugs to be fixed promptly. You want support in optimizing the software. You can afford to pay us a lot of money, because the software makes and saves you much more money when it works and when it works with you in a smooth way. Therefore you would sign a support contract with us. Since big money is on stake, we can afford the transaction costs involved with collecting the money. If your optimizations and customizations are your trade secret, we license our software to you using a proprietary license.

A consequence from the above thinking is that not every software package can take advantage of this business model. For this, the software package must have the following attributes:

  • Be useful for both private individuals, small businesses and big businesses.
  • Be “tinkerable” i.e. facilitate development of enhancements and add-ons by individuals with bright ideas.
  • Be such that optimizations and adaptations to meet special needs would yield significant profits or savings in the right place.
  • Be critical to the functioning of some of the big businesses, which use it.

Typically, such software is dual-licensed, usually under the GPL and a proprietary license.

Computerized Elections in Israel

Background Information

The Israeli Ministry of Interior is planning to computerize the process of elections in Israel, using electronic voting machines. They are planning to start by running a pilot in ten settlements during the upcoming Nov. 27, 2007 council elections.
Sources:

This is a Bad Idea

The following reasons are given for the move to computerized elections:

  1. Reduction and even elimination of rigging votes and multiple voting.
  2. Election results availability few minutes after end of elections.
  3. Budgetary savings.
  4. Ability to vote from anywhere without special procedures.

Unfortunately, the first three reasons are either untrue or are insufficient justification for switching to computerized elections.

  1. The worldwide experience with election machines is that they are not secure, not well-designed, violate anonymity of votes, and facilitate rigging of votes even more than paper based ballots.
    Sources:

  2. Election results are not available if the voting machines develop technical problems, as they did in several elections in the world. A more fundamental point is that the integrity of the election process is worth the wait until the next morning. Confronted by the choice between rigged elections with speedy results and clean elections with results available only after 10 hours or so, every sane citizen would choose the second alternative without thinking twice.
  3. Any budgetary savings from using election machines are wiped by bad policies adopted by corrupt politicians, who got elected to office thanks to corrupt elections process. This is one place where one could be penny wise and Pound foolish (or one million wise and ten billion foolish).
  4. The fourth goal of computerized elections can be accomplished by alternative means – for example, by using computers only to verify that a voter did not already vote elsewhere. Paper ballots can still be used for the actual votes.

See also:

It is to be noted that the talkbacks to the news items about the Israeli Ministry of Interior plans demonstrate that Israelis are clueful about the dangers of electronic elections.

What Can be Done About This?

  • Find which voting machines will be used in the pilot and publicize audit results and cracking tips available from other countries where they were already used.
  • Refuse to vote in the voting machines during the pilot.
  • In the pilot, the results from the electronic voting machines will not have official use, so it may not be unlawful to actually crack into them. DISCLAIMER: IANAL. CONSULT WITH YOUR LAWYER BEFORE DOING ANYTHING ABOUT THIS SUGGESTION.

Book review: Steve Krug’s “Don’t Make Me Think!”

DON’T MAKE ME THINK! – A Common Sense Approach to Web Usability, Second Edition
© 2006 Steve Krug
Author: Steve Krug
Pages: 201
Publisher: New Riders
ISBN: 0-321-34475-8
The book introduces the principles of Web usability, and explains how to overcome political obstacles to actual implementation of usable Web sites. Being an introduction, the book is rather superficial. However, it has several footnote references and a section devoted to Recommended reading, which would benefit people, who want to learn more about Web usability.

In practical world, Web site design and implementation is fraught with politics, due to the large number of stakeholders in a typical organization. The book covers the political aspects as well, even though its title does not reflect this fact.

The book is very readable, and is rich with colorful illustrations. To fully benefit from the book, the reader should have browsed Web sites and to have participated in a Web site building project.

The book was designed to be readable in a single flight. I actually finished reading it in less than four hours, excluding pauses. In my opinion, it meets very well the needs of beginning Webmasters, and of busy executives in charge of Web site design projects.

The book starts with an introduction, which explains why the book is thin, and what was left out of it and why. Chapters 1-5 cover the guiding principles, which can be summarized as follows.

Krug’s Laws of Usability:

  1. Don’t make me think!
  2. It doesn’t matter how many times I have to click, as long as each click is a mindless, unambigous choice.
  3. Get rid of half the words on each page, then get rid of half of what’s left.

Principles:

  • Create a clear visual hierarchy.
  • Design pages for scanning, not reading.
  • Conventions are your friends.
  • Users like mindless choices.

Facts of life:

  • We don’t read pages. We scan them.
  • We don’t make optimal choices. We satisfice.
  • We don’t figure out how things work. We muddle through.
  • Steve Krug’s wife: “If something is hard to use, I just don’t use it as much.”
  • People won’t use your Web site if they can’t find their way around it.

Chapter 6 treats the subject of Web site navigation, covering search, breadcrumbs and tabs. It also introduces the “trunk test”.

Home pages have their special technical and political issues, so chapter 7 discusses home pages. An home page needs to answer the following questions:

  1. What is this?
  2. What do they have here?
  3. What can I do here?
  4. Why should I be here – and not somewhere else?
  5. Where do I start?

The conscientious Web designer will find in chapter 7 also a list of the top five plausible excuses for not spelling out the big picture on the home page, along with arguments, which refute those excuses.

The next two chapters, chapters 8-9, deal with the politics of designing for usability and present usability testing as a way to reduce the impact of “religious arguments”. Chapter 9 provides also a list of the top five plausible excuses for not testing Web sites, along with their refutations.

Chapter 10 deals with the benefits to an organization from improved usability of its Web site. Chapter 11 covers accessibility. Chapter 12 deals with the politics of bad design decisions and how to overcome them.

The following points pertaining to politics are covered by the above chapters:

  1. Home page design is fraught with politics, because there are several stakeholders.
  2. Usability testing is presented as antidote to religious arguments in the Web design team.
  3. People are afraid that better accessibility degrades the experience of non-disabled users.
  4. Bosses want to ask too much personal data.
  5. Bosses want to add “sizzle” to the Web site.

The author’s Web site is at http://www.sensible.com/.
The first edition of the book had three chapters about usability testing, which were condensed into a single chapter in the second edition. The original text of those chapters can be found in http://www.sensible.com/secondedition/.

The book was reviewed also in Amazon Web site: http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0789723107

The following are reviews of the first edition of the book:

The following is an interview with the book author: Meet the MasterMinds: Common Sense Web Design with Steve Krug.

sitecopy – basic usage, pointers to more information, tips

When you maintain a Web site, it is a good practice to hold in your PC a mirror of the Web site’s contents. When you want to modify the contents, you edit the files in your PC and then synchronize the Web site’s contents with the copy in your PC.

To actually synchronize the files, you have several possibilities:

  • Individually FTP modified files to the Web site. Manually delete from the Web site files, which you deleted in your PC.
  • Create a tar ball of the modified files, FTP it to the Web site, and then untar them remotely. Then manually delete any files which you deleted in your PC. You need also to make sure you missed no modified file in the tarball.
  • If the Web hosting services provides a rsync server, you can use rsync to synchronize.
  • If you can set up a rsync server on your PC, you can invoke rsync on the remote Web host, if you have shell access to it. In this case, you need also to poke a hole in your PC’s firewall.
  • Use the sitecopy command, the topic of this blog post.
  • There are also other commands with substantially the same functionality as sitecopy.

Homepage for the sitecopy project: http://www.lyra.org/sitecopy/
Should I use sitecopy? http://www.lyra.org/sitecopy/why.html
Freshmeat project information: http://freshmeat.net/projects/sitecopy/

To use sitecopy under Linux, you need to create the file .sitecopyrc in your home directory. The following works for me (replace words with ‘you’ by names relevant to your situation):

site yoursitename
  server yourwebdomain.com
  username yourremoteusername
  # password ________________ # sitecopy will prompt you for your password
  local /home/yourlocalusername/websites/yourwebsite  # Your Web site's mirror
  remote /        # FTP home directory for your Web site
  ftp usecwd      # FTP will upload files only to the current working directory
  permissions all # Set permissions of files after uploading
  permissions dir # Set permissions of directories after uploading
  safe   # Block uploading of files, which were updated on the Web host.
  exclude *~  # Exclude backup versions of files modified by you
  exclude /.bash* # Do not delete dot bash files in the Web host.
  exclude /.svn   # or /CVS if you use CVS rather than subversion.
  exclude /*/.svn
  exclude /*/*/.svn
  exclude /*/*/*/.svn
  exclude /*/*/*/*/.svn
  exclude /*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/.svn

(The above illustrates also a problem which I had in systematically excluding directories by name.)

To actually run sitecopy, create a shell script file with the following command:

sitecopy -u --debug=ftp,files,socket --logfile=/home/yourlocalusername/sitecopy.log yoursitename

The logfile will be few MB long for a Web site with few hundreds of files, but if you encounter any problems, the logfile will help you diagnose the problems.

I found that sometimes I need to run

sitecopy --catchup yoursitename

before uploading some files, because the safe option seems to be overzealous at times.

Hasamba-style Questions about Windows Vista Sales

It was publicized that Microsoft sold 40 million licenses of its Windows Vista OS. The question is if this is for real or not?

For real:

  • Microsoft’s revenues during Q1 2007 were reported to be much higher than in previous quarters.

But more than 10% of those revenues are deferred income from the Software Assurance program, which is being recognized now.

Reasons to doubt whether those numbers mean much:

  • The already publicized reason – it is not known whether those licenses represent PCs and laptops already sold to the public, or still in warehouses.
  • How many developers received licenses as part of their MSDN subscriptions?
  • How many licenses were disbursed at no extra cost to those, who paid for Software Assurance during the last few years?

And I still do not mention the question how many people tried Windows Vista and then switched back to Windows XP. In those cases, Microsoft already got the money for the Vista license, and the customer got several more gigabytes, with which to fill his bookshelf.

Debugging the mechanism of sending feedback on GPLv3

I am subscribed to the GPLv3 Information mailing list. About two weeks ago, the new draft of GPLv3 was announced. I reviewed it and had four comments.

I tried to submit the comments via the provided E-mail address. The system requires you to associate your comment with a fragment from the GPLv3 draft. I associated my comments with fragments as requested.

All four E-mail messages bounced back to me – the fragments were not found in the draft.

I sent a bug report (gnu.org #333022). I was told that I found a bug in the comments handling system, and that now the bug has been fixed. I was asked to resubmit my comments. I resubmitted all four comments.

I got messages about delayed local delivery of my E-mail messages, but no confirmations of receipt of my comments arrived.

Another bug report was sent (gnu.org #333429). Again, apology for the problem with the E-mail system. The problem was fixed, and I was asked to resubmit my comments, which I did today.

This time, confirmation messages arrived after less than 5 minutes (Comment #2930, Comment #2931, Comment #2932, Comment #2933). The status of the above comments can be tracked by surfing to the appropriate link. For example, Comment #2930 can be tracked by browsing http://gplv3.fsf.org/comments/rt/readsay.html?id=2930.

I feel proud of myself. Not only did I make some comments, but I also cleared the way for other people to contribute to this very important review of the GPLv3.

Avoidance of wheel reinvention vs. NIH – possible influencing factors?

Basically, this is a true story. However, some of the details were made different from what happened in reality.

Once upon a time, in a nonprofit organization, which will remain nameless, a volunteer sysadmin set up a PC to serve as the nonprofit’s public server, serving few Web sites, managing mailing lists and some other services.

The guy was clever and configured the OS (Linux) on the PC in a nonstandard but highly secure way.

Few years later, other volunteers took over the PC. They preferred not to bother to learn how the system is configured and how to administer it. They preferred instead to reconfigure the PC to a more conventional and familiar configuration.

End of story.

The arguments, which erupted due to the above preference, led me to ponder the general question: when and why do software professionals prefer to reinvent the wheel?

On one hand, operating systems and computer languages are not, as a rule, reinvented all the time. Most people are content to learn an existing environment, become expert in it and stick to it. Only very few venture forth and write a new OS or a development framework for a new programming language.

On the other hand, when confronted by legacy software or existing installation, several people prefer to discard any existing work and start from afresh.

What differentiates among those two extremes? I tried to build a list of the relevant variables:

  1. How well is the framework designed for extensibility or for building upon it?
  2. Quality and thoroughness of documentation – especially instructions how to make changes to the system.
  3. Amount of wisdom invested in the basic system design, which is worthy of learning due to its own sake.

In the case of the above story, the first two variables seem to explain the reluctance of the other volunteers to use the first volunteer’s system.

Finally a test for aptitude for programming?

It is well known that it is impossible to use currently available tools to test for ability to program computers.

In their paper The camel has two humps (working title), Dehnadi and Bornat claim to finally have a test, which can predict one’s ability to program. Basically, their test assesses the candidate’s ability to manipulate symbols according to rules without looking for a meaning in those symbols.

A note to self:
According to the above paper, the following are the major semantic hurdles, which trip up novice imperative programmers:

  1. Assignment and sequence.
  2. Recursion/Iteration.
  3. Concurrency.

Novice declarative programmers have to leap the following semantic hurdle:

  • Argument substitution.

In addition to the above semantic hurdles, I know of one additional major semantic hurdle:

  • The concept of a pointer.

I wonder whether there are additional semantic hurdles, listed in some obscure (or not so obscure) paper published somewhere in the world – or even unrecognized so far.