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."
...can anyone explain Vista's schedule in light of this discovery?
My turnips listen for the soft cry of your love
"But if software is at all interesting, it's because no one else has done it before."
"Interesting" to me means something new and/or unknown...mostly. There are exceptions. Treading new ground always requires greater effort. If I cut a my way through virgin jungle then those who follow have a path.
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
One programmer is better than two for the same reason that one woman in the kitchen is better than 2. You have to get on a pretty large scale before you need multiple cooks/programmers.
Software programming in general is hard for 2 reasons:
1. Computers aren't built for interfacing with humans, thus UI us terribly time-consuming.
2. The environments people like to drop an app into can be so bizarre, that rock-solid stability is very difficult to achieve.
The government can't save you.
and of course, we are the better programmers, so better fire those other 8.
Whatever testing is done often only tests that the product produces the correct answers when feed the proper input - no account is taken for how the program reacts to incorrect or incomplete data.
Changes are requested faster than they can be implemented and often are not communicated very well.
In short there are systemic failures throughout the whole process, from inception through to delivery. There is no single answer to why software is hard and there won't be until the industry matures and people start to get thrown out of the business for acting unprofessionally
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Programming websites that let you actually view a page without requiring a cookie is obviously hard for the folks at Salon.
OMG!!! Ponies!!!
I would say the reason a lot of projects, even small ones take so much time is that requirements cannot be defined.
Compare building a house to software. Before you build a house
Schedule times can slip but you still know where you are in terms of progression.
If we built this house the way we do software development
Yes, writing software is hard, especially writing good software. The hardest part is to make things simple, even harder is to make things simple AND flexible. The need for a thorough analysis is greatly underappreciated.
Incompetent developers tend to make things more complex than necessary. From that point on, under economic pressure, workarounds are needed to get things done. This in turn makes things even more complex than necessary. THAT is what makes writing software hard. The problem is, it is difficult to be aware of the skills that we lack. As such, a lot of programmers with a huge ego don't deserve one.
I'm not into Extreme Programming per se, but I've noticed that if multiple people look at a piece of software, chances of problems going undetected get smaller and smaller. Yes, even if you, a master programmer, show your code to a rookie, the chance of bugs going undetected will reduce. In fact, it will inevitably result in more bugs being detected before rolling them out to customers.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Two of us typed this. We thought it might be faster.
I don't think I can fully agree. I think software development may be hard, but that's never the main reason projects fail. The main reason projects fail in my 10+ years experience is because of product managers, not coders.
Product managers I have seen (and I have seen many) often don't know zilch about technology, but even worse they usually also don't know much about their market, target audience/users, User Interfaces, project management, etc.
Consequently they simply don't know what they want and aren't able to explain it in one coherent paragraph of sentences. Once they would be able to explain it, the actual coding would be half as bad.
So if this guy complains that their projects back in the days at salon went bad, I'm not suprised. He's not a coder after all, he was a typical clueless product manager - started out as a journalist and suddenly he was responsible for a type of product he knew nothing about: CMSs, in addition to having no other qualification in software development or a related area (UI design, project management).
So am I surprised this project didn't succeed? LOL, of course not.
You wouldn't let a journalist build a space shuttle or a car now would you? But software? Sure, software is easy, anyone can do it. In the end, it's probably not harder than building a car, but not easier either. it just takes proper skills for all roles in the team, is all.
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
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.
"Ideas are not the product of labor."
Respectfully, I have to disagree. Some of my best ideas have come from pondering over a problem. Pondering can be effort. It's not like daydreaming. To think about a problem and apply logic to try and come up with a resolution requires effort in many, if not most, cases.
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
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.
I take game programming classes. One of the instructors made some very good points related to innovation. His context was game wise, but since my background is business application programming, I can easily see how it applies here.
When you innovate in a game, only make one....maybe two innovations. Otherwise, you skew so far away that you usually end up a complete failure. Applying it here: sure, keep things interesting by doing some piece new, but keep it manageable by keeping the rest of it "boring". You gain predictability while retaining "fun".
Layne
Implementing a good design is usually half the battle. Creating a good design is usually the other half, but in practice, a solid design is almost always the part that gets skipped. Let me bore you with a brief anecdote.
I have a large, global project underway. User requirements are done and have been done, and we're turning those requirements into things we can code or deliver ("View a workorder", "Print asset detail", "Group revisions into single document"). Of that, we have 150 odd deliverable items, not to mention all the fit/ finish work we may have to do, and all of this barely touches on reports, security roles for users, etc.
The reason we're going to make our date, despite the 1280 discrete requirements we need to test, is that we've taken the time to look at the requirements from a few different angles and come up with a solid design plan, before even thinking about implementation. Each piece will build on another, really hard parts are identified early, blockers and such are flagged ASAP. We know things will emerge that we didn't expect, but we've got the biggest chunks identified and working together on paper. We have the flows mapped out, exceptions and variations listed, and a user group that has to sign off on every iteration of the incremental build (we're spiraling out functions and features).
The only thing "hard" about all of this is the incessant thinking about the details, and discipline required to focus on the un-fun part of software construction, i.e. the planning and design walkthroughs. The itch to code something already is growing, but delayed gratification means that when the time comes to actually write something, the design will almost certainly lead to a working, if not optimal, solution. We can refactor as we go, but it needs to work completely before it can work efficiently.
I've been following Chandler off and on, somewhat through Spolsky's references to it and some stray links around the web, and sounds like design didn't go deep enough into what it'll really take to build some of the pieces.
-BA
Why doesn't anyone complain about how hard brain surgery is? Why doesn't anyone complain about how hard building space exploration vehicles is? Why doesn't anyone complain about how hard creating a successful marketing campaign is? Software engineering is difficult because it's a complex subject that takes a combination of intelligent people and training to produce good results. Just because businesses are too stupid to realize this doesn't make the problem go away. You can't throw complex projects at untrained, stupid, incompetent people and expect them to produce quality software. You can't just invent some magic formula for software development that will work 100% of the time to maximize efficiency. Software engineering is NOT manufacturing. Accept it and move on for fuck's sake.
"Just disagreeing on our definition of the word "labor".
That's what I was doing; and within the context of a specific provided example.
Think about it. It might take some effort."
Okay troll, right. I've put some effort into it and I'm still clueless. Are you talking about "Ideas may come in a flash, or evade forever."? If so, I consider that a partial truism. Ideas also come about from a slow, plodding, methodical effort. Your generalization is half-assed. If you've got a point to make, please do so. You haven't stated how you disagree with my (and the general use) definition of "labor" and you certainly haven't clearly provided your interpretation of the context involved in the "specific provided example".
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
I believe his point isn't that you're not doing work, but rather that scheduling pondering is impossible. Otherwise give me a fairly firm estimate of when you will either prove P = NP, or that you can prove that P < NP. Logical deduction isn't precisely the same as "resolving the unknown". One doesn't provide a time table for when the Twin Prime conjecture will be solved. I can apply logic deduction to lots of problems, but I can't necessarily provide a firm estimate of when I'll find the solution to a problem.
Any time you provide an estimate of the time it will take to do anything in "problem solving", you are using statistical conjecture about how long you think it should taken given that you've solved other similar issues. How long will it take me to resolve a logic puzzle. How long will it take to construct a proof to show something? You think logically on those, but you don't provide a schedule. If you tell me, I'm going to give you 30 different distance, rate, time story problems that are geared for a high school freshmen, I can tell you that I'll be done in about an hour. If you tell me that you'd like me to prove Fermat's last theorem without using reference material. I know it's true, and I know that I can't provide a schedule for it. It's highly unlikely that if I took the rest of my life I couldn't do it. Both require deduction and logical thought. One is an entirely different scale then the other.
When working in the unknown, you can't provide a schedule. Otherwise, you'd be working either in the known, or very close to the edge of known.
KirbyThis question was asked and answered in 1986. Why is it on Slashdot as if it was a new idea every two months?
No Silver Bullet: Essence and Accidents of Software Engineering
Fred Brooks had much the same material in _The Mythical Man-Month_: communication overhead spirals out of control in large groups, project scope creeps out to infinity without a budget, overconfident people try to do too much and fail, it's impossible to know what the customer wants and (in a new area) even what works until you've built something and watched how it fails, only make change to known-good baselines, etc.
This author had to discover Fred Brooks after he'd started a career of big projects. TMM should have been in his school curriculum.
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 read somewhere that in science fiction writing this is called "The Tooth Fairy Principle". Don't introduce more than one exotic technology or idea. I immediately realised that it applied even more strongly to software development. New areas represent areas of high risk, adding even a few to a project can change the risk from moderate to very high. I've participated in a few projects who broke this principle ... as usual commenting on the risk that this implied only made me sound like a Cassandra when eventually the prediction bore fruit.
However, the major reasons I see for software projects becoming late are: clients repeatedly wanting to change design after the design phase (in one surreal case we had a client change a fundamental design issue 24 hours before going live!), poor resource allocation (a very large subject), management saying yes to unrealistic deadlines, bleeding edge technology (Tooth Fairy Principle - high buzzword compliance).
Bitter and proud of it.
Daunting at first. But once you get some instruction, it is actually a whole lot easier than it seems. I've even learned to make 3D models. Another thing that once you find out how to do it right, it's really pretty easy.
In fact, I think that some of my business experience helps me more than others in the program. I have a better feel for structure within a process than most of them. Scope / Requirements / Design / Code / Test translates into the game world as Pitch / Game Design / Technical Design / Code / Test (with Art being like having a Web Tech team that does the HTML and Styles for you).
But if you ever did any old school Windows programming (where you had to actually hand roll your event loops), that's basically the core of game programming. Everything else is event handling (fire event, score event, death event, etc.) and calling libraries (graphics, sound, etc.). Granted, that's boiling it way down, but equating it that way should give you an idea of how easy it really is.
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.
Read it. Know it.
Why must we rehash this over and over again.
If it were easy, then yes, we would have push-button frameworks that magically created programs. What bothers me more than the ignorance of the "no silver bullet" mindset, are the pushers of programming environments that supposedly will solve all our problems. Bullshit. Corba sucks. EJBs suck. All these things suck. Just write good software and stop looking for the golden chalice.
"No matter where you go, there you are." -- Buckaroo Banzai
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.
If some barrier would have kept CPU speeds below 100Mhz then I imagine that by now people would be developing very efficient code and that we would still have the same level of application performance that we enjoy today with our dual core 2Ghz processors.
Sorry to break this to you, but apps today are not faster than the ones they replaced. We used to write more efficient code, and had more spartan interfaces, because we had to. But I don't think Microsoft Office today is noticably faster than the WordPerfect / Lotus 1-2-3 type apps we wrote in assembler under DOS. All that extra CPU power is more than eaten up by layer upon layer of slower and slower software.
All this allegedly to make programmers more productive. I haven't seen that either.
rd
Delivering Good Software is difficult because of the people involved.
By the way, I read the article and this paragraph:
Disclaimer: Scott Rosenberg was responsible for Salon's hiring me 10 years ago, was my editor and boss for many years, and is a close personal friend. My daughter baby-sat his twin sons as I "interviewed" him. So I'm utterly biased and completely partial. But "Dreaming in Code" is still a darn good book. - is one of the reasons why software sucks. I have seen too many cases of friends hiring friends not because the people being hired are the best that could be found (or that interviewed) for the job, but because they are friends of the friends. This touches on all avenues of life and business, the best people for the job are not hired, because friends of the friends are hired and those people more often than not are not going to do the job right.
One should either recommend a person for a position or interview the person, but not both.
You can't handle the truth.
Let me tell you why it is hard.
A person needs to cross a river, and so believes a bridge needs to be built.
What he should be doing is ask: "I need to cross this river, can you help me?"
Instead, he asks someone to build a bridge, a bridge of this and this dimension so his particular vehicle can pass, and a bridge with this and this feature because "it would be nice if..". He also wants a bridge that looks in this and that way, because since he is paying for the bridge he wants it to look the way he wants it to.
First he was crossing a river, he is now building a bridge. Will the bridge help him cross the river? Who knows? Maybe a bridge like he imagines can't be built, or only be built poorly.
Its the same thing with software. People want the strangest things. In fact, what they WANT is the only thing they know. They don't know what they NEED.
So you get an organisation, a business, with an office that has a problem, any problem. The problem will ALWAYS occur because some OTHER process isn't working somewhere else in the organisation. You get bad data from here, and the clerk is expected to output good data out there. In the 50's I bet they wanted more filing capability or better typewriters to solve these problems, in this day and age they want IT. They want a system!
So instead of using excel, notepad or even a piece of paper like any other sane human being would to keep track of the information, a yell echoes down the corridors: "We need software to support our business."
So some programmers are hired. They get a description of the problem, which isn't logical in the first place, and they are expected to solve it. Their tool, software, is built using a logical language. It is used to describe the data, and solve the problem by adding a few flows for that data during certain conditions.
So the programmer (or bridge builder) sits himself down. The first 10% of code/thought he outputs is usually all that should be done about the percieved problem. That is, a description of the Need.
The next 90% of coding is about the programmer trying to coerce a logical language around non-logical flows and non-optimal solutions, hammering a square button into a round whole, with GUI's, buttons and special extra functions for special extra cases, and those extra wants on top that really describe other problems.
So we will end up with a mishmash of buggy code that describes the wants of the customer. The Want to solve a problem that should have been solved with organizational changes, or changes in the work processes. But hey now everyone is happy again, software is supposed to be a bit buggy, the organisation is obviously still working non-optimally (software can't fix that), but at least the clerks now have webpages to input the bad data in as long as the servers are up.
Optimally, the programmer (yes the programmer) should look at the problem, trace it down the whole organisation, yea trace the customer Want to the REAL problem and the REAL need, proceed to make the organizational changes and be done without an IT system at all.
We all know that won't happen, but that is what should be done. Don't expect a logical function (software) that describes a non-optimal situation, to function in an optimal way.
Software doesn't work that way, thats why its hard.