This question just really interested me, so I got curious to know what the community thinks. What do you guys think is the most difficult type of software to write? I write government software and have found it's pretty hair-pulling, but I'm sure there are far worse things out there.

+3  A: 

Government software can be pretty hard just because it seems like the Govt Agencies don't know left from right most of the time.

Other strong candidates would be software for the financial industry which has to have extreme precision and as-close-to-real-time-results as possible.

+10  A: 

The most difficult and hair-pulling software to write is software that already exists. It always takes me an extra portion of self-discipline to do that.

Edit: Actually, I have to correct myself. Even more difficult is it when you know that the software that you are writing won't get used, because it is in C# and the new CIO will throw everything away that you have built, and will replace it with Java. Making sure that your C# application is still going to be as good as it can be is extremely difficult. :-)

Definitely. It never seems to be the good software that already exists that needs work either!
+16  A: 

The most difficult software to write is any software that isn't well defined. e.g. no specs, no product/project manager, design by committee, etc.

Nah, that's easy! You just make stuff up then the customer tells you to change it, and change it again, and again, and you bill them by the hour.
Adam Pierce
well it's pretty difficult making all that new "stuff" up :D
So, any kind of open source software? :)
Greg Hewgill
I dont agree!! Thats the most easiest one. Both the client and you have no idea what the end product would be :)
Damn, there's me thinking this was a joke answer :)
I was going to reply with the same message myself.
Edwin Buck

Some of the government requirements that I've seen can be pretty arbitrary (or at least seem that way) and really restrict "natural" styles of programming. I can definitely commiserate with that.

Andrew Flanagan
+7  A: 

Couple year old article about the dudes who write shuttle software for NASA:

+1 for that software take controls of 4 billion piece of equipment, the lives of a half-dozen astronauts, and the dreams of the nation.
+29  A: 

I would think that the most difficult software to write would be mission critical software such as software for airplanes, space shuttle etc where failure is not an option and lives are on the line. When writing that sort of software, not only do you have to code and test it but you'd have to prove that there is no possibility of failure.

I recommend the link provided by Dana as it definitely backs up my point:

The group writes software this good because that's how good it has to be. Every time it fires up the shuttle, their software is controlling a $4 billion piece of equipment, the lives of a half-dozen astronauts, and the dreams of the nation. Even the smallest error in space can have enormous consequences: the orbiting space shuttle travels at 17,500 miles per hour; a bug that causes a timing problem of just two-thirds of a second puts the space shuttle three miles off course.

NASA knows how good the software has to be. Before every flight, Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle. If Keller can't go, a formal line of succession dictates who can sign in his place.

While there are rigorous checks in place to make sure sign off can happen without hesitation....its those rigors that are far above the peer reviews in most companies that I believe classify it as difficult programming. In spite of the rigorous checks in place, how many programming noobs would be allowed to contribute to the code base? I'd think that anyone employed for such a job would have many years of experience before being invited onto the team.

Also, as mentioned in the comments below, medical software would fall under this criteria too. Who would wear a pacemaker that was programmed by some cowboy coder? Not me that's for sure.

That's not difficult at all, I did some of that stuff for Siemens. The reason it's not difficult is because you follow very strict checklists designed to ensure no suspect code ever makes it out of the lab onto a potentially destructive device.
Medical software would come under this banner too. Fine if you are a methodical programmer but not fine if you're a cowboy.
Adam Pierce
Formal verification is also easy to do — which proves it's correct.Check out Cryptol.
interesting read!
I actually asked a question about space hardening recently (, looks like the brass ring of bug free code is biting a lot of people here:
Tim Post
I've shown the NASA article to my coworker. I loved his response: "Hey, we do just the opposite!"
Interesting; I'd interpreted the question to mean technical difficulty, not… well, "emotional" difficulty, I guess. This is an excellent point, too — I don't think I'd be comfortable with people's lives depending on software *I* wrote, and I consider myself to be pretty good!
Ben Blank
If you think that writing mission-critical software is difficult, think about how difficult it must be to write static analyzers for such software (e.g. aiT or ASTRÉE), and *then* think about how difficult it must be to write software that automatically generates such analyzers (e.g. PAG).
@Goran, I just laughed pretty hard out loud. Your coworker is funny ;)
I appreciate ALL of your answers, but I think this is, and although this is probably subjective, the most difficult type of software because not only do you have the pressure of having your software work, but you have the pressure of people's lives in your hands--literally.
+4  A: 

Installers. Not a one of the tools is worth a damn, and there are always situations you didn't count on (remote profiles, locked DLLs, /etc/braindeadness, root vs. non-root access issues, etc.). Add that to the fact that no one every wants to be "the installer guy" and puts it off until late, and you've got a recipe for misery.

I've never had much issue with writing installations. I create MSI's using InstallShield (well worth the cost), and I write my own custom actions in Delphi (or you can write them in C) for anything that needs extra logic.
I use WIX and had a lot of fun writing multiple transforms and a 'managed' custom action. Besides, even with its difficulties, it's not that hard.
+6  A: 

Any kind of highly-concurrent application. Balancing liveness and safety among threads, not to mention testing for the desired result across the many edge cases, is always a challenge and frequently underestimated.

These days, there are groups who specifically build frameworks for these types of scenarios, so that most of us don't have to. See MapReduce from google (there is a chapter on it in the book Beautiful Code).
+3  A: 

Research code can be hard in a way because by definition, you don't understand the problem that well and the results of the program are supposed to tell you something interesting about the problem domain. Therefore, it's hard to figure out where to draw lines of abstraction in your code because you don't know how it will evolve.


From what I've heard, stuff that has to preserve binary backwards compatibility can be insanely hard. Not only is your freedom limited by legacy, but you have to think about all kinds of ABI minutae instead of just coding something that works.

+2  A: 

I would guess financial industry software. Finance company development shops have a reputation for being chaotic, stressful working environments with little or no formal development processes, yet with insane deadlines (e.g. days) and very demanding customers. "Just get it done" is something I hear a lot from friends who work in that industry.

Mission-critical software like the shuttle software is generally supported by well defined and very organized software development and QA processes, so the development process should not be so stressful. Also, the operating parameters are pretty well defined up front.

Ken Liu
+7  A: 

The most difficult software to write is software for which you don't have clear requirements from your customer (whoever the customer may be).

David Segonds
...there's other software?
+1  A: 

Frankly, I'm voting for Games -- a combination of high performance requirements, large complicated object models (for game objects), intrusive interplay between the model and the view, intimidating deadlines, and messy overlap between core programming ans scripting.


Navigation software, particularly if it has to work in multiple countries.

C'mon, that's really just glorified A*.
Ha! I wish. A* is just the routing algorithm, which is about .01% of what goes into it. You also have guidance, positioning, map rendering, map data compression, and a bunch of other stuff, all on a device that usually has significant resource constraints.
@nshaw: how does all that get harder when it has to work in more than one country?
+8  A: 


As someone (might have been Tim Sweeney?) said, "at 60 frames per second, everything is performance critical".

They typically have to write much (if not all) of the game from scratch within a couple of years, and there's no chance of a version 2.0 to get it right - if you don't get it right in 1.0, you won't get to make the sequel.

And then you release it to an incredibly jaded audience with amazingly high expectations, for a relatively cheap price. Most office software costs quite a bit more, and they get to resell a new version with minor tweaks every few years - luckily for them businesses tend to complain less about price than gamers...


Form my personal expirience I would say medical software. Last time I did medical it seemed like an endless amount of special cases and funky rules with all the varying types of insurance, then you have a million and one privacy rules as to who can see and do what. You could gather requirements until your blue in the face and not cover all the special cases a hospital could come up with.

Neil N
+10  A: 

Robotic weapon systems. Realtime functions, some at 60 Hz at least, with safety critical functions, with a weapon. The purpose of the system is to kill those people there, while not killing those other people over there. Doing that on a tight budget, for government customers. The goverment are going to want changes. LOTS of changes, which will be delivered for free.

As a co-worker used to say "The difference between normal operation and an atrocity is just a matter of timing".

The operator is going to be eighteen to twenty-five years old, and is not interested in what might or might not be hard for the programmer. He's trying to stay alive. Other people are tying to kill him. Clippy the paper clip will not win friends here.

Oh, and the hardware gets shot at, bombs hit it, so the peripherals are tricky. Power goes off at random, people swap peripherals whenever they get broken.

Oh, and lots of people don't like what you do for a living.

Apart from that, it's pretty easy.

Tim Williscroft
Sorry, off topic, but I'm curious how you consider the moral implications of what you do - do you think it's morally neutral(/irrelevant) to make weapons, or that it's morally positive for anyone to make weapons for their own country, or only morally positive to make weapons for some countries (and if so, how you decide who it's okay to make weapons for)? Also, does it worry you that political leadership can change, and that a weapon you design now could be used in a war you are morally opposed to in 10-15 years?
I think its morally bad. Not an expected answer.Go find a bunch of books on moral philosophy. Look up sections on the morality of making war. On the morality of making weapons of war. On the morality of the use of violence. There isn't a lot of content, that wasn't written by philosophers sleeping peaceably in their beds at night only because rough men stand ready to do violence on their behalf; My apologies to Orwell.War is bad. Being invaded is worse. Being well armed does seem to make other countries mostly leave you alone. Terrorists are a different kind of problem (try Predator-B).
Tim Williscroft
Sorry for continuing a political discussion on a tech website, but there's no way to send a private message to a user, so I guess I'll post one more thing here. Re: "Being invaded is worse", nearly every war in history has been portrayed as defensive, by *both* sides involved. I'd link to the famous quote by Goering, but Godwin's law in 3 is rather tacky (even though in this case the point of course wouldn't be to compare your country to Nazi Germany, but instead to remark that if such a tactic can work for an extremely evil agenda, imagine how well it can work in a more ambiguous conflict).
If your government does things you don't like, vote them out*. All citizens are responsible for their governments. Vote, reform corrupt electoral systems and if needs be, vote with your feet and move country. *If your governemnt is not an elected one, my sympathies. Try another country if you can.
Tim Williscroft
ironic commentary coming from someone called "keysersoze"
Ken Liu

Software that people actually desire or have a use for.


Real-time, safety-critical, embedded operating systems.


Paul Nathan
+5  A: 

Software, often in a corporate environment, that the end users don't actually want or need.

I've worked on a few projects where it became evident that although management want it, the actual end-users had strong feelings against it, for various reasons.

It's a real test to work hard on an application when the end-users made it quite clear we we were wasting their time.


Correct software.

As in absolutely free of bugs, and provably so.

-- MarkusQ

P.S. See Principia Mathematica for a taste of how hard this is.


I would have to say re-writing and/or adding new features to old applications. It's not just about remembering what you wrote and why you wrote it that way, you also have understand what that part of the application does in relation to the rest of the application, what interactions it has with other classes, modules, etc.

I one time rewrote a function that would parse lines from a config file, and create arrays of strings. Once I finished, I tested the new function and it worked fine. But, when I ran the application it didn't work, and till this day I don't know why or what was happening. It was so weird that I just decided to revert to the previous version (thanks SVN) and forget about it.


There are many ways to define "difficult". A lot of the other answers focus on cases where quality requirements are extremely high. Though I think of "difficult" programming as what requires an amazingly talented developer to do. Basically, think of the best programmer you have ever met, and what is a software application which only that person would be able to write due to the level of code complexity and/or sophistication required.

I'm actually not sure my answer, but it would seem like some of the core parts of game engines or operating systems would be really difficult.

+1  A: 

Regular expressions. :)


Fixing architecture bugs/functionality in a legacy code with 100% backwards compatibility is pretty painful experience.

Daniel T. Magnusson

Software that cannot be completely tested in it's entirety. Years ago a friend's brother was the head of an agency that was given the task of writing 'Star Wars' (as in the anti missile missile system) software. He rejected the task because there was no way the system could be completely tested. It would have to work perfectly the first time it was used when it could only be tested for discreet alternatives, and not what would be confronted in battle time conditions.

+3  A: 

Software without a blueprint and changing requirements.

Jas Panesar
I completely agree. I currently have to work off a customer requirements spec, as the architect didnt bother with anything else...
Hopefully you were able to make a blueprint before you began to ensure the client agreed to how their requirement spec will be fulfilled. Otherwise the "this is what we said but this is what we really need" can come out.
Jas Panesar
+1  A: 

It is hard to write good software for an industry you are not familiar with. I mean, if you have spec, you can write a software that accomplishes the task, but having a bit more insight, you could come with much better solutions.


the maya software

+2  A: 


They may not be as hard in the normal sense as real-time, mission-critical, or space/medical BUT think about writing the compiler used to build those systems.

There are many things about compilers that make them difficult. To write a compiler you have to know:

Regular expressions
Grammars (LL1, LALR, etc.)
Intermediate Representations (IR)
Code emission per target platform
Optimizations, in-lining and loop unrolling to name a few
Liveness analysis
Data structures
- recursive structures for the nesting of code blocks
- object layouts in memory supporting vtables, inheritance, overloading and overriding
- Lattices
- Control flow graphs
- Data flow graphs

Constant Change

In addition to all that, there will always be some new language construct dreamed up or a new hardware feature that needs supported by the compiler. Even if neither of those change, there will always be pressure to find more and better optimizations for existing languages and platforms. You could spend your entire career in one small area like type-checking or register allocation and still have an inexhaustible supply of improvements waiting to be done.

Kelly French

Poorly specified software.

Dan Diplo