What the DOS Era Still Teaches Me

I got my first computer when I was ten, in the early 1980s. It was an Apple II. A home computer in those years did what you told it, and nothing else.

That feeling has never left me. It is also where my favourite habit comes from: lean code.

AppleSoft BASIC and a lot of disks

I learned to program in AppleSoft BASIC. There was no search engine to ask and no package to install. You had a few lines, a small amount of memory, and an idea. If the idea was too big, you made it smaller.

The Apple II came out in 1977, so it was already a few years old. Every program I wrote had to be short enough to finish.

My first love in tech was Beagle Bros. I had many of their disks. Apple Mechanic was one of them. The company started in 1980, and Apple Mechanic came out in 1982. Those disks were small, clever and a little playful. They taught me that a tiny tool, made with care, can be better than a big one.

A small company in high school

In high school, in 1990, I started a small software company. I called it T-Software House. It was a small company, and a small start.

FoxBase and the floppy disk shuffle

In my first year at Chiang Mai University, I built my first real software in FoxBase. It was a proper program, and it had one big limit. It did not fit on one disk, so running it meant swapping floppy disks.

If I wrote that logic in plain words today, it would look like this.

LOAD program FROM disk 1
WHILE user IS working
  IF next screen IS NOT on this disk THEN
    ASK user TO insert the right disk
    WAIT until the disk is ready
  END IF
  SHOW the screen
WEND

Nobody likes that. But the limit made me think about what the program really needed, and what it could leave out.

FoxPro and real business work

After FoxBase, I moved to FoxPro and used it for many business projects. Business software gets used every day, and people notice when it is slow or confusing. That work kept the same habit alive. If a feature was not needed on day one, it waited.

Karaoke on Windows 3.1

Later I wrote karaoke software for Windows 3.1. Microsoft released that version on 6 April 1992. I sold my software to many shops in Chiang Mai and Bangkok.

A shop owner does not care how clever the code is. They care that it starts, works and does not get in the way. That is a good test for any software.

Lean code, then and now

The tools changed a lot. Floppy disks went away. Memory grew from kilobytes to gigabytes. The habit stayed.

I never decided to keep it. It just stayed, from BASIC to FoxPro to Windows 3.1 and on to the web. Each new tool gave me more room. Each time, I found that the work was still better when I used less of it than I was allowed.

For me, lean code means a few plain things.

• Build the smallest thing that works, and put it in front of someone early.
• Leave out what the first version does not need.
• Measure the size of what you ship, because a small thing is faster for everyone.

The smallest thing that works, today

I try to follow the same rule on this site and in my projects. Two examples are public, so I can show them.

NativePress is a WordPress plugin with an Expo app. The plugin has its own REST namespace, nativepress/v1. It serves lightweight Markdown instead of the default heavy wp/v2 output, and the app draws it with native components. You can read more on the NativePress page.

This site is the second example. The home page went from 25.3 KB to 7.8 KB over the wire after I turned on compression. I measured that with the raw and gzip sizes of the page. Same page, same words, far fewer bytes.

Neither change is clever. Both come from asking the old question: what is the smallest thing that works?

My rule for new features

When someone brings me a project, I use the same loop I would have used on the Apple II.

WHILE project IS NOT shipped
  IF feature IS NOT needed TODAY THEN
    CUT it
  ELSE
    BUILD it, TEST it, SHIP it
  END IF
WEND

WHILE project IS NOT shipped
  IF feature IS NOT needed TODAY THEN
    CUT it
  ELSE
    BUILD it, TEST it, SHIP it
  END IF
WEND

It is short, and it works. I like it because it is honest. It asks whether the feature is needed today, not whether it is nice to have. Features that are cut are not lost. They go on a list, and we look at them after the first version is live.

If you have an idea and you are not sure how small the first version can be, I am happy to talk it through. You can also see how I work on the services page and the notes.

Where this comes from

The personal story is mine. The dates for the Apple II (1977), Beagle Bros (1980), Apple Mechanic (1982) and Windows 3.1 (6 April 1992) come from public history sources. The page sizes for this site come from my own compression check on the home page. NativePress is described on its work page.