Michael Eriksson
A Swede in Germany
Home » Software development | About me Impressum Contact Sitemap

Software development: Category Contents

Here various issues relating to software development are discussed, ranging from general, abstract principles to highly specific advice, and from the central to the peripheral.

A separate page with a discussion of terminology and similar issues relating to this category, itself, is the recommended starting point.

The sub-category on Webdesign is recommended to anyone who deals with that topic.


I have often discussed various issues relating to e.g Unix vs. Windows, text based systems vs. WYSIWYG, etc., in real life (and in several of the articles here). Often, the counter-part has made a besser-wisser remark along the lines of “That is how you want software to be. Others can be different and you cannot presume to dictate how software should be written for them.”—which misses one of my main points. In fact, it practically turns this main point on its head. Fearing that it will be the same here, I elaborate:

Software companies presume to dictate too much to their users and make too narrow assumptions about their end users, the users’ needs and wishes, and how the users will (wish to) use the respective piece of software. My point is that they should not, but that they should give the users more flexibility—not “force users to X instead of Y”, but “do not force users to Y but give them the choice between X and Y”. (Also note what I consider the possibly most important rule of UI design.)

Notably, a flexible interface, as common with many older Unix-verse products, will not be much more complicated to develop, might even save developer time in the long run, and will often allow not just X and Y but A–Z.

In addition to this, however, there are many objective problems with current software, software training in schools, whatnot, that go back to ignorance, faulty methods, a lack of knowledge of non-GUI paradigms, and similar—and these problems appear to grow worse year by year. The world would be a better place, were this rectified. In particular, software intended for software developers (and the actual software developers, themselves) must be considered with a far higher base-line of “computer literacy” than products intended for the masses. (This too, I note, is not a matter of my dictating, but of my presenting superior alternatives with a corresponding reasoning.)

Indeed, much of the poor software written today is poor because stakeholders, requirement makers, and (to a smaller, but growing, part) developers simply do not know what alternatives are available or are highly prejudiced about the alternatives. Indeed, as computers have grown ever more present, the average computer literacy among users has dropped—and too many of the borderline illiterate consider themselves highly literate because they know MS Office...