What is the most difficult type of software to write?

Question

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.

Answer 1

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.

Answer 2

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. :-)

Answer 3

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.

Answer 4

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.

Answer 5

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

http://www.fastcompany.com/magazine/06/writestuff.html

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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

Answer 15

Games.

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...

Answer 16

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.

Answer 17

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.

Answer 18

Software that people actually desire or have a use for.

Answer 19

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

:-)

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

Regular expressions. :)

Answer 25

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

Answer 26

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.

Answer 27

Software without a blueprint and changing requirements.

Answer 28

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.

Answer 29

the maya software

Answer 30

Compilers

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
Scanning
Parsing
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.

Answer 31

Poorly specified software.