Slashdot Mirror
Why Software is Hard
GoCanes writes "Salon's Scott Rosenberg explains why even small-scale programming projects can take years to complete, one programmer is often better than two, and the meaning of 'Rosenberg's Law.' After almost 50 years, the state of the art is still pretty darn bad. His point is that as long as you're trying to do something that has already been done, then you have an adequate frame of reference to estimate how long it will take/cost. But if software is at all interesting, it's because no one else has done it before."
Programming websites that let you actually view a page without requiring a cookie is obviously hard for the folks at Salon.
OMG!!! Ponies!!!
I design buildings for a living, and I've dabbled in programming, and I think architecture and software development have a whole lot in common.
Your step one in "building a house" can go through all 6 of the steps that you have listed for software development. We get hired by clients, sometimes they have a good idea what they want, sometimes they don't. Sometimes what they want is feasible, sometimes it isn't. It's not unusual for even smaller projects to drag on for years, because the client keeps changing his/her mind. Many projects that cross our desks will never be built.
Many projects are not the traditional design phase ->building phase. They often overlap, and it's pretty messy.
I could go on for paragraphs with the similarities that I see between software design and architecture, but I'll save that for another post.
One time I threw a brick at a duck.
I think that once someone improves the situation of software architecture and programming languages so that programmers don't have to mess with ad-hoc hacks but instead write the logic that they want to implement, then software will cease to suck.
The main problem is Operating Systems architecture and Programming Languages.
Due to lack of time, I will only list a few of the Operating Systems problems that weren't solved after more than 30 years of OS development:
This would also get rid of the unnecessary bootup/shutdown sequence all programs are currently dealing with.
Instead, a capability-security model should be used (not POSIX capabilities, but EROS/KeyKos type ones), which is much simpler to use, verify and much more powerful and fine-grained. This would also facilitate secure movement of components between computers - which could be done automatically by the OS to improve performance. More on that on a later post.
One thing I've noticed about companies is that they try to treat programmers like factory workers. Expect each one to be interchangeable and jump in anywhere on the "assembly line" at any place at any time for any piece of code. However, programming takes understanding, and complex programming takes complex understanding. Even a good programmer fixing a bug may need to analyze surrounding code for several hours before changing a single line.
Unlike most engineering projects that are completed and done, most programming is a living growing process that is constantly changed modified and improved.
That implies that there is a need for specialisation and clear boundries, to assign "ownership" or "territory" over certain parts of code. A programmer who understands it and gets the last say on how it's changed and have clear non-arbitrary rules for changing that "territory". Like in open source projects. If you want a kernel fix, you submit it to the proper maintainers, or make your own fork, but no corporate bureaucrat comes along and micromanage how the code is merged and managed.
Most cooking projects don't take more than 10 man-hours, but pretty much every programming project does. And, furthermore, mostly when the chef makes a mistake it's obvious to her.
:)
Neither condition hold for programming. It's for this reason that I think that, in general, *two* programmers can program faster than one. At least, me and my partner can program code that's more bug-free together than we can when we program separate projects, and that makes a difference. If the project is sufficiently large - i.e. takes longer than about 10 hours, the cost of communication between two people is less than the cost of switching.
While we're at it, I think that there's another misconceptions in this interview.
programmers are programmers because they like to code -- given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter
Two of the five developers at my little software company are programmers because they like to figure things out. So we almost always figure someone else's code out before we do anything ourselves. There are varying degrees of this in a lot of the developers we've got there. I would say that none of us will write anything ourselves unless it saves us a considerable period of time.
But even more, if you had a relative who was always wondering, "What is it that you do all day?" you could hand my book to that relative and say, This is what my work is really like.
No. I couldn't. My experience as a developer is nothing like what he's described. And he didn't talk about the phenomenon of unknowns that I've noticed - for every project I do, if I estimate how long the known things will take, dealing with unknowns will generally take 60% longer (so multiple time estimates by 3 is generally correct). He didn't talk at all about testing.
Almost everything he talked about are things that I thought would be true when I started but that have ended up more or less untrue. Discipline coding makes a difference. Automated unit testing catches most problems, and regression testing finds almost all the rest, and not everybody does these things.
Mod me down and I will become more powerful than you can possibly imagine!
Actually, every instructor I've had works in the industry. Not *DID WORK*....but *WORKS*. Classes are at night. It's in Austin, so there are plenty of studios to pull from. I've had instructors that have worked on games from all eras and genres. Some of the companies that represents: Sony and SOE, Midway, NCSoft, and Microsoft. Plenty who have started their own studios after having worked at bigger ones, too.
http://www.austincc.edu/techcert/Video_Games.html
It's not a degree program (yet), but I'm not too worried about that since I already have a CS degree. For me, it's more about having fun, learning some new stuff, and making good contacts for when I'm ready to jump into the industry.
Check out the list of names on the Advisory Board and the list of Instructors. There are some influential names on that list.
Layne
I sometimes wonder if it's a questions of people who naturally see things as images, versus people who don't.
Anyway, I'm with the grandparent. A small class or state diagram can be useful to me, but I get lost very quickly in a big or detailed one. And when I go into details, I soon find that what I want to say is easier to express in text, where I am not limited to the few languages permitted by the UML.
This thread is full of analogy after analogy.
I think if you want to have a discussion amongst people who develop a software you have to ditch the analogies, because none apply. The reasons software development takes longer that you might think, or the reasons software is difficult to create, sometimes doesn't give the expected return, sometimes is buggy, etc, doesn't have anything to do with cars or buildings or spacecraft.
// MD_Update(&m,buf,j);
The article's title gives an indication of this (as some other comments have pointed out): it talks about "programming" but not "software engineering" as a whole.
Still many companies hire people with not enough computer science knowledge, for performing software engineering tasks. You can do this, but the results cannot be good (at least in the long term).
I think this is because software is usually successful, in the short term. It apparently solves the problem and the customer gets satisfied. Therefore, why "losing" time and money making documents (where experience gets archived) or performing a good design?
If you create software, how often do you (your organization) apply these concepts?:
- Life cycle of a project,
- Gantt and Pert diagrams,
- Risk management,
- Ishikawa diagrams,
- Code complexity,
- Software quality assurance,
- Coding style standards,
- Documentation standards,
- Software patterns...
Have you ever wondered why Linux is still failing to widely conquer business marketplace?
Satisfaction - both for companies and indivual programmers - should be switched from being creative to getting a good job done. We still have much to learn.