My first large-scale experiment with AI programming didn’t go so well. I used Claude Code and told it to generate an Android version of an iOS app. About 90 minutes later, it had produced a passable version of the app’s home screen, but nothing else. I had to redirect it several times to fix errors and get something that would build. It cost me $67.

I’d say it failed to give me a commercially useful result, but I learned a lot. Later that day I was using it easily to do smaller incremental tasks. Then I signed up for a company account and invited my team.

AI is coming for our jobs. That’s the prediction, the fear, the worry that we hear every day. Some say it’s here already, others will tell you it’s coming in so many months or years. The closer you are to the technology, the sooner you expect it to disrupt everything. Is it for real?

My company writes software as a service. I work with dozens of business customers so I have access to a wide range of input. I don’t yet have any customer who is outright using AI to replace our services. Most are more interested in putting AI in their products or on their web sites. A few will ask ChatGPT for bits of advice and pass them on to me. I use ChatGPT too, so I have access to the same information.

I don’t doubt the day will come when non-programmers will be able to build viable applications without coding. But there are different kinds of non-programmers. A competent and detail-oriented worker who understands their business should get good results. An executive who’s used to barking out vague commands to their underlings isn’t going to get what they want.

This leaves a window for us to take advantage. Right now people still need a developer to guide the AI tools, give them coherent instructions, check their results. If you code, you should absolutely have these tools at your disposal and use them. Generating complete applications from scratch, while possible, isn’t the only way to go. You can ask for individual features, review them, and make sure you understand them before you accept the code. Even if you’re not using AI for codewriting you should at least be using it for code review or to do mindless refactoring jobs.

I don’t think larger and more conservative businesses are getting ready to replace their entire coding teams with AI. When a business is using technology, rather than selling it as a product, computers are a means to an end, and technological progress isn’t always a priority. I’ve run into plenty of cases where decades-old equipment and software were happily being used on a daily basis. Everything evolves eventually, and we must be prepared for the future, but we shouldn’t ignore the present either.

Long term? We’ve trained AI to be good at writing software, but it begs the question of whether much of the software we use today will even make sense in a future of ubiquitous AI. Why do you need a calendar app when you can just ask your AI assistant to remember your appointments? Why do you need tax preparation software when you can just say, “Do my taxes”? Will IDEs, filled with screens and options and plug-ins, be necessary when AI is writing most of our code?

Will we even need need languages like Swift, Java, or Kotlin when AI can spit out the executable code directly? Even the elite developers who make our most important programming tools aren’t safe.

I like writing software. I’ve been doing it more than four decades. Even if I have AI writing code for me at work, I’ll still maintain my personal applications by hand, much like a woodworker is going to keep building furniture in his garage that cannot compete with the flat-pack fiberboard from Ikea. Even then, I’ll at least point my AI tools at my code and ask them to review it. Not to save time, but to see what I can learn.

Technology is change. We might not like it, but that’s what we signed up for when we became software developers. If I hadn’t been willing to change, I’d still be writing BASIC programs on a TRS-80. Or more likely, sitting in a bar somewhere complaining about how much better the world was when I was writing BASIC programs on a TRS-80. That ain’t for me.

Maybe society will collapse when we all lose our jobs to AI. Maybe we’ll lose our retirement savings when the AI companies fail. Whatever happens, few of us are in any position to change it. You’re either prepared for it or you’re not. I’ll face it with my eyes open.

We call them apps instead of applications because they’re supposed to add small, incremental bits of functionality to your phone. It used to be that you could go to the App store and buy modest but useful apps for a few dollars, and start using them immediately, almost as you would use a web site.

But things went sideways pretty fast. Today, apps try to shove in as many features as possible in an attempt to keep up with their competitors. If you just need something simple, you might have to wade through dozens of screens to find it.

And it gets worse. Every app asks you to create an account. Every app wants you to subscribe. I'm all for paying a fair price for a piece of software, but I'm not going to "subscribe" to a calculator app that doesn't provide any ongoing new material. I don't want to create an account if the only reason for doing so is to give the app developer a way to send me spam.

Here is my manifesto: the principles I'll use whenever I develop my own apps. I encourage all good and noble programmers out there to adopt them for yourselves.

No Servers

Does your app really need a server? It might, if it has to share data with other users, or access information that isn't directly available on the internet. But if it can work without a server, it should. Store data in local databases or local files. Use cloud storage to back it up or make it available to multiple devices.

No Accounts

Does your app require that users have accounts? If you aren't building an app that is part of an existing web service, it probably doesn’t. Even if your app has a server, you can generate a random account and store the credentials in the user's cloud storage or keychain — allowing them to use the app and access their account from multiple devices, without having to surrender their email address or remember a password.

No Internet

If your app does use internet services, it shouldn't be dependent on them to the extent that it becomes useless (or crashes) when they aren’t available. Every app should expect internet outages and plan for them. Use local data stores to download or cache needed data in advance, and stage outgoing data for delivery later. If you are using a remote database, learn how to synchronize it with a local store in your app. Tip: Avoid autogenerated keys. Use UUIDs or natural keys instead.

No Subscriptions

Asking people to subscribe to an app just to keep using it is a shameful money grab. If your app does a fixed thing, charge a fixed price. If you want people to be able to install your app for free and pay later, then offer a genuinely useful tier of free functionality and a one-time purchase price to get the rest. Obviously there are exceptions for apps that provide streaming content or other ongoing services that cost money to produce. But, you are not Adobe. You don’t employ hundreds of developers and release major new versions twice a year.

No Ads

If your app has to stop and show the user a full-screen ad, you've immediately cut its usefulness in half. If they were considering paying for your app before, the ad is more likely going to motivate them to delete it. Ads are obsolete — they don't make any useful amount of money. Find some other way to earn revenue if you need the revenue.

Put the User First

Users want to open your app and start using it. If your app hits them with an immediate solicitation for money or a request for personal information, you aren't serving the user's needs, you're serving your own needs. Build good software that people want, and they'll pay you for it, without your needing to trick them or strong-arm them into doing it.

App stores used to be good at enforcing these kinds of rules, but over time, they've given in to greed. Don't let that deter you. Be a better developer, produce a better app. Rise above the fray. Make apps great again, starting with yours.

Recently I read a blog post from Dr. Randal S. Olsen in which he plotted an optimal road trip to each of the lower 48 state capitols, solving what is commonly known as the “traveling salesman” problem. We consider this problem impossible to solve definitively, but it’s certainly possible to create algorithms that give a pretty good approximation. Olsen’s circular route is 13,310 miles in length. Could I do better? I thought it would be fun to try.

I’m not that great at math. So for me, an elegant algorithm full of tricky calculations wasn’t going to be the way. I needed something I could understand.

Enter Brute Force

“Brute force” is a term we use to describe programming that’s inefficient or inelegant. If it works at all, it’s only because computers are fast enough that it doesn’t matter. Brute force programming is easy to write because it works the way an average person thinks — bubble sort is the classic example. So what’s the brute force solution to this problem? Just calculate every possible route and sort them to find the shortest. Easy!

Easy, until it sinks in that the number of possible routes is 48!, approximately 1.24×10^61. To call this number large is an understatement. By comparison, there are only around 10^56 atoms in the solar system. If my computer could process a trillion routes per second, it would not even make a dent in the problem before the sun exploded. So that ain’t going to work.

What about computing routes completely at random, keeping track of the shortest one found so far? I didn’t think it would work but I was curious how close it could get. So I got a list of GPS coordinates to the capital cities and calculated the distances between each (actual math!). I decided to use the straight-line distance between the cities as an approximation and plot the result on Google Maps later to get the true driving distance.

I coded it up and ran it. Of course it spit out some huge numbers at first, 30,000+ miles. As it ran, it started finding shorter routes. I let it run overnight. By the next morning I was looking at routes near the 20k mark for distance (and I knew that the actual road route would be longer once I plotted it). I did some code optimizations but soon realized this was not going to give me the answer I wanted.

Brute Force, but Refined

I decided to revisit the idea of brute force, which I described earlier as going about the problem the way a person would. So how would a person do this? They are probably going to pick a starting point and then just go to the next closest place. Since there are only 48 starting points, it was easy to try this, and easy to see that it wasn’t the solution. When I examined Dr. Olsen’s map I could see that there are many cases where the route doesn’t in fact take you to the next closest city. A good example of this occurs in the area around Albany, which acts as a bottleneck between New England and the rest of the country.

Still, it was obvious that each city was at least connected to a nearby city. There’s no chance that an optimal route is going to have you drive from Boston to Little Rock in one shot. I changed my random route generator to pick one of the five closest points as the next destination. I added some additional optimizations such as bailing out early once the route exceeded the best found so far. I let it fly.

This worked much better. I got routes under 20,000 miles pretty fast. After a couple of hours it came up with what I call route #10639, because it has a straight-line length of 10,639 miles. When I plotted this on Google Maps and added up the driving distances, I got 13,055 miles, 255 miles better than the goal. Success!

Over the next week I made various changes to my code and ran it for a lot more hours. None of those runs produced a shorter route, and in fact most of them ended up reproducing route #10639.

The Optimal Route

Here’s a map view of the winning route:

View the result on Google Maps to get a closer look.

For much of the route we’re traveling along the coasts or the national borders, as you might expect. The hard part is knowing when and in what order to visit the interior cities. In this solution, we cover 11 of them in a detour between Montgomery and Jackson, and the rest between Helena and Bismarck. It’s a far from obvious route, yet it emerged as the shortest among several billion alternatives.

To get this result we had to make the non-intuitive choice, on several occasions, to bypass nearby cities for more distant destinations. Indianapolis and Frankfort are only around 200 miles from their counterparts in Ohio and West Virginia, yet we don’t visit them until thousands of miles later. Harrisburg eschews its three closest neighbors, routing you to Charleston or Albany depending on your direction of travel. The detours to the interior cities could have started anywhere along the northern or southern borders.

There were two runners-up that are worth a look. Route #10652 is 13,132 miles, and route #10676 is 13,166, both shorter than the goal1. It’s interesting to compare the maps and see where they differ. Route 10652 sends you from Santa Fe to Oklahoma City instead of Austin. In 10676 we see one change in New England when visiting the three northernmost cities.

Some Technical Details

I used an M1 Mac and wrote my program in Java. Since the M1 has 8 cores, I ran 8 threads. It’s easy to do this because the threads only have to interact with each other to decide who’s currently got the best solution. I can check around 250,000 routes per second with this arrangement. ChatGPT kindly provided a list of the GPS coordinates I needed, and a function to compute the distances between them.

Each route begins at a random location and branches out from there, choosing from a list of the next N nearest destinations (omitting those we’ve already visited). I tried various values of N between 2 and 16. N=8 produces the winning route most often. If the number is too small, we miss the cases where the route bypasses a lot of nearby cities; too large, and we waste too much time looking at bad solutions. I think it might make sense to have N be dynamic and get smaller as the route is nearing its end, but I haven’t tried it.

Is there a shorter route? My intuition says that if there is, I’d have found it. Perhaps you will implement my algorithm, or something like it, and prove me wrong.

Final Thoughts

We all have computers that sit idle when we aren’t working. Long running algorithms like the one I describe here are a good way to put those resources to use for little or no extra cost2.

Most of the software problems we solve in our day to day work require fast response times, and I don’t want to discourage you from looking up and using established algorithms to solve them. But I also want you to keep in mind that there’s still room in software development for novel solutions. Don’t fall into the rut of always settling for the standard way of doing things. Someone is going to invent the next great computer algorithm that’ll change the world, and it might as well be you.

Goofus and Gallant grew up to be software developers.

Gallant is a consummate professional. He studies project requirements carefully, asks a lot of questions, and spends plenty of time planning his approach before he starts programming. Gallant says that getting things right up front will save a lot of time in the long run.

Goofus is a maverick. He jumps in and starts coding right away. Goofus figures he can always go back and fix the code later if it doesn't work out.

Gallant believes in automated testing. He writes unit tests and integration tests, and sets up a build server to run them. He prepares test scripts for the QA team to use. Goofus says that testing is the customer's responsibility.

Gallant takes advantage of source control. He always makes a new branch when he works on a feature. Gallant spends a lot of time managing his branches and resolving merge conflicts, but he likes to be sure that his code is well tested before it gets into the product. Goofus saves time by writing all his code on the main branch.

Gallant adopts the latest software management practices. He divides his time into sprints and uses his company's project management software to document his work plan and progress. After each sprint he takes time to review his results and adjust his estimates for the next one. Goofus jots down a rough list of tasks on a notepad and keeps it on his desk while he works.

Gallant's project is six months late. He has many uncomfortable meetings with his boss during which the economics of software development are discussed. Gallant is steadfast in his belief that good programming practices are essential and that quality software development takes time. He tells his boss, "If you don't have time to do it right, when will you have time to do it over?"

Goofus enters a hack-a-thon contest. He wins first prize by coding a new social media app in 24 hours. Goofus quits his job and uses the prize money to start up a company to bring his app to market. The developer who takes over his old job complains that his code is a mess and will need to be rewritten from scratch.

Gallant's project is finally finished, but his company soon announces a round of layoffs. Gallant's name is at the top of the list.

Goofus raises 20 million dollars and takes his company public. He retires from programming and uses the money to hire a team to finish his app. When Gallant shows up for the job interview they hire him right away because he seems like just the kind of developer they need to get their software under control. Goofus spends most of his time meeting with investors. He does television interviews in which he attributes his success to dedication and hard work.

Gallant tells his new boss that their team needs more process. Getting things right up front will save a lot of time in the long run.

Once upon a time, real programmers wrote code. We had a computer, a C compiler, and a couple of books full of algorithms. The books never had all the answers so we invented our own solutions. We dug in and figured it out.

Today we "leverage" code. We make a dependency file and list out the software we want to use. Before we write a line of code ourselves, our project has inherited hundreds of third-party packages that promise to do everything we need. What is all this code? Where does it come from? Nobody seems to care.

We're convinced that we're saving time this way. Our managers are convinced they're saving money. In reality, we're just trading one problem for another. Don't know how to write a database query, send a push notification, schedule a batch job? Instead of spending hours learning how to actually do these things, you can spend hours installing a package from a sketchy web site, written by an anonymous graduate student, and figuring out how to use it by reading Stack Overflow posts.

In a couple of years your application will quit working. There will be an operating system change, a new security requirement, or a web service that no longer responds. The graduate student, now a manager at a biotech firm, will have long since abandoned the project. The code they left behind is incomprehensible. You'll be forced to start over with... a different package.

Real programmers are still around. We have better computers now, and we’ve learned the latest languages. We write code if anyone lets us. But we are sensitive. We don't like to be called names like "old-fashioned" or "obsolete". So we try, as best we can, to go with the program and use the packages. We want to keep our jobs.

One day society will collapse. Without access to package repositories and web sites, we'll be the only ones left who can program a computer. We'll be the heroes who rebuilt civilization. Admittedly, it's more likely that we'll be the first ones to die after the supply of frozen burritos and Starbucks coffee runs out.

Until then, when nobody is looking, we break out the C compiler and keep the tradition alive. We open a text editor. The code flows.

I don’t buy object-relational mapping, at least not in Java. It's not because JPA or its implementations aren't well written, but because the concept itself robs capability in exchange for conveniences we don't really need.

Relational databases have a lot to offer. SQL is a rich language that can perform complex queries, bulk data updates, computations, summaries, and more. It can address not just rows but individual columns, and it can join tables even if they weren't formally set up to be joined. By contrast, ORM takes a limited view of the database as a series of objects to be manipulated individually and atomically. Create, read, update, delete.

When I interview a Java developer with an ORM background, I ask them to explain how they'd do some specific things:

• Update one property of an entity, or a series of entities that meet a criteria. I'm looking for a solution that does not involve reading the entire entity from the database, updating the property in memory, and writing the entire entity back.

• Produce a report that involves grouping and summarizing data (for example, total sales per region for a given quarter). I prefer solutions that don't involve creating a report-specific Java class for every such report.

• Read a row within a transaction in such a way that its data is guaranteed not to change for the duration of the transaction. What I want is the equivalent of the SELECT ... FOR UPDATE statement in SQL.

You can accomplish these things with JPA, but the majority of developers don’t know how. So, what else can we use if not ORM? Surely we can't just go back to using SQL queries and plain old JDBC, right?

Taming JDBC

JDBC is ridiculous. You get a connection, create a statement, apply parameters, execute it, and iterate over a result set. You pull properties from the result one at a time and do something with them. Everything throws an exception, and everything must be carefully closed to avoid resource leaks. You end up with 20 or 30 lines of code to do one SQL query. If we did that for every query, we'd have an endless morass of code on our hands.

But our job as programmers is to simplify, refactor, and reuse. In a production application, we can hide the details of JDBC in our own functions. We can use generics, callbacks, reflection, and other language facilities to reduce the amount of JDBC overhead per query. I have done just this on many projects.

I won't present my code in detail because what I wrote is specific to my projects. It is intended to be a design pattern rather than a reusable library. But I'll show some of the end results in a moment.

Result Mapping

Building objects from database results is a mainstay of Enterprise Java. We assume that without an ORM, we'd be reduced to writing mountains of tedious, error-prone code like this:

customerID = resultSet.getInt("customer_id");
customerName = resultSet.getString("customer_name");
customerEmail = resultSet.getString("customer_email");

In fact, it's pretty easy to automate these assignments using Java reflection. You can infer the property names from the column names, or write your own annotations to customize them. I typically put the functionality into the base class of my model objects, and access it via a constructor that takes a ResultSet.

Yes, it's some effort, but it's the kind of thing you can do once and reuse for an entire project, or even an entire organization. You can make it work exactly the way you want, and you can easily override the default behavior and process ResultSets manually when necessary.

Putting It All Together

Here's an example of what a data access function might look like:

public List<Appointment> getAppointments(int patientId) throws SQLException {
    String sql = "SELECT * FROM appointment WHERE patient_id=?";
    return this.queryForList(sql, Appointment.class, patientId);
}

There's nothing here that isn't straightforwardly related to the task at hand. It works because the "queryForList" function encapsulates the complexity of JDBC: it knows how to create a Statement out of the SQL string, how to apply the paramters (passed as Varags so more than one is possible), and how to create instances of the indicated class from a ResultSet. It does all of this using code I wrote myself, without relying on an ORM tool.

What if the result doesn't map one for one with a Java object? In these cases, I use a different function that has a callback. It gives me access to the ResultSet without having to manage any of the other JDBC objects:

public Map<Integer,BigDecimal> getTotalsByProduct() throws SQLException {
    String sql = 
"SELECT product_id, SUM(amount) as amount FROM receipts GROUP BY product_id";

    Map<Integer,BigDecimal> totals = new HashMap<>();

    this.queryWithPopulator(sql, new Populator() {
	@Override
	public void nextResult(ResultSet rs) throws Exception {
	    totals.put(rs.getInt("product_id"),
              rs.getBigDecimal("amount"));
	}
    });

    return totals;
}

I could have solved the problem by creating a Java object with "productId" and "amount" properties, but I didn't really need any such object, so I chose to put the results directly into a HashMap. I use the same technique to handle one-to-many relationships (inner JOINs) by writing code that creates a new object only when the ID of the outer table changes.

Think For Yourself, Write Your Own Code

The methods outlined here are not theoretical. I've used them sucessfully in large, professional projects. I also work with ORM when I'm on teams where ORM was chosen by another architect, so I appreciate what it can do. But I feel more comfortable knowing that I can write any SQL statement at any time, and process its ResultSet any way I want. Programming is about writing code, and sometimes that means building up our own code libraries that best suit our projects. We should not shy away from it.

Editor's note: This was originally published on March 16, 2008.

Someone showed me an early Palm Pilot. I was hooked immediately and bought my own a few days later.

In those days, a Palm Pilot had a lot of deficiencies. Memory was limited to 8MB, the screen was a paltry 160x160, and switching between programs was slow and cumbersome. But it was worth it for the novelty of having a touch screen computer small enough to fit in a pocket.

Some years later I heard about the Palm Treo, and picked up a Treo 600. Having a PDA and a phone together was the right idea, and the possibilities of an internet-connected Palm platform seemed endless. I installed the development tools with the intention of building a side career as a Palm applications developer.

The Treo 600 was fun for a little while, but it didn't take long for reality to sink in. The camera was too crude to take any kind of worthwhile picture. The screen, though color, was still only 160x160. Memory was only 24MB, and the applications were old and familiar — not in a warm way but in a way that makes you wonder what they'd been doing for the past five years.

Writing Palm applications was a shocking revelation. If you wrote Windows code in the Windows 3.1 days, you'd be right at home writing code for Palm OS because Palm is every bit as crippled and clunky as 16-bit Windows running on top of DOS. Cooperative multitasking, no memory protection, limited memory space. Dereference a nil pointer and crash the entire device.

I bought a new Treo in 2007, but it was only marginally better than the first one. The screen and the camera were a little better. The memory situation, the applications, and the programming tools were the same. The web browser stunk, third-party apps were terrible, and the whole thing was just too slow. Often it locked up or crashed when I was trying to do something basic like answer a call.

Watching Palm devices evolve was like watching the PC revolution in slow motion. What PCs gained in a year took the Palm people a decade.

In the meantime, Apple gave us a phone with a real computer in it — and a user interface that genuinely makes sense. When I used a Treo to browse the web, I expected it not to work at all; if I managed to get what I needed, I felt a deep sense of having pulled off something remarkable. With an iPhone it just works.

I hate being wrong, and I hate seeing so much work go down the drain, but it’s time to be honest: Palm blew it. With a ten-year head start, they could have owned the mobile market, but they squandered their advantage. Mobile is now Apple’s game, and while I may wax nostalgic for my Palm Pilots and Treos of the past, you can bet that Palm isn’t getting any more of my mindshare or my money.

I remain an enthusiastic iPhone user and iOS app developer to this day.