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."
So, 50 years ago programmers were trying to solve the exact same problems wer'e trying to solve today? What Windows software was around in 1957?
...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.
not only software, every project is hard if it first of its kind. the fact that we have ready-made ingredients available does not mean that we know the right combinations and permutations and design from the start. a good engineer can build a great bridge out of stone, while an idiot wouldn't even if given best concrete and machinery but no helping brains.
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
I'm not sure I like the way this is going. Software is HARD. The jungle is VIRGIN. Uh-oh...
Programming websites that let you actually view a page without requiring a cookie is obviously hard for the folks at Salon.
OMG!!! Ponies!!!
An approach like this would probably have been helpful in FBI's failed $100 million debacle the Virtual Case File system
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
Treading new ground always requires greater effort. If I cut a my way through virgin jungle then those who follow have a path.
The problem is even thinking in terms of "effort." Ideas are not the product of labor. Time with a chain saw is proportional to length of path cleared.
Ideas may come in a flash, or evade forever.
KFG
Anybody who tries to program anything thorough, complex or unorthodox knows in great detail what Rosenborg means when he says, "software is hard", and that even trivially simple projects take eras to complete.
You would be astonished, how many subtle bugs, memory leaks, logic errors, inconsistencies, typos, misinterpretations of specs, functionality, etc. can quietly mug your simple program. If you add multithreaded functionality as well, you introduce a whole new class of horrendous synchronisation, race-condition, resource starving, deadlock, memory corruption, instability, etc errors.
Once you start with multiple files, header files, ridiculously complex make scripts (these are very popular) and odd dependencies on obscure libraries, you can while away many a dull evening having fun fixing things.
If you have multiple programmers working on the same thing, then you tread on each others toes, can't understand what other people have written, somehow manage to subtley break someone else's code, can't agree on what to call object X, have to call a commitee meeting, time wasting...
I've spent many days, trying to figure out why my train goes through the wrong signal, and after a week, discover that I've saved something in one register, then used it again to save something else two lines down, then pushed and poped it for no apparent reason.
Then if you simultaneously click button X while holding key Y, memory in arbitrary position Z is modified and your program starts acting really weird and then crashes ten minutes later...
Developing properly robust, indestructable code varies proportionally to an unfortunately high power of program complexity.
I've spent many dull evenings trying
There is no psychiatrist in the world like a puppy licking your face - Ben Williams
Two of us typed this. We thought it might be faster.
It should be pointed out that the author is not a software engineer and really does not know what he is talking about. Professional developers who want to understand what makes software development difficult should read some of the textbooks on software engineering that he quotes.
Wrong tools: C and C++ language. Overcomplicated APIs: Win32, HTML, drivers, JAVA, etc... Lack of standards enforcement: HTML disaster. All this makes it easy to derail any project.
And as Mattel once pointed out, "Math is hard!"
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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.
SO many points of failure.
At the lowest level, there are bugs made by the programmer. There can be misunderstanding also, especially if there is cultural differences in the organisation.
When multiple programmers are involved there are even more points of failure relating to the interface. Does the module behave as expected? Is the documentation accurate?
At the highest level, is the design accurate enough? Do we even know exactly what we have to do? Do we have the resources or is there wishful thinking involved?
And then, because it can take such a long time to write software, specs change during development. There is people turnover, changing customer need, chainge in direction, etc.
The points of failure are incalculable. The thing to do is adhere to best practices and then take the estimated amount of time to develop and multiply by 2 (in some places, experience will show 3).
And most importantly, don't lose any sleep because of this. Don't want to die at 60 of a hard attack because of software development.
Linux violates 235 Microsoft patents.
Some of my best ideas have come from pondering over a problem.
What I did not say is that thinking is easy.
KFG
Surveys / SURVEY: INFORMATION TECHNOLOGY
Make it simple
Oct 28th 2004
From The Economist print edition
The next thing in technology, says Andreas Kluth, is not just big but truly huge: the conquest of complexity
IMAGE
“THE computer knows me as its enemy,” says John Maeda. “Everything I touch doesn’t work.” Take those “plug-and-play” devices, such as printers and digital cameras, that any personal computer (PC) allegedly recognises automatically as soon as they are plugged into an orifice called a USB port at the back of the PC. Whenever Mr Maeda plugs something in, he says, his PC sends a long and incomprehensible error message from Windows, Microsoft’s ubiquitous operating system. But he knows from bitter experience that the gist of it is no.
At first glance, Mr Maeda’s troubles might not seem very noteworthy. Who has not watched Windows crash and reboot without provocation, downloaded endless anti-virus programs to reclaim a moribund hard disc, fiddled with cables and settings to hook up a printer, and sometimes simply given up? Yet Mr Maeda is not just any old technophobic user. He has a master’s degree in computer science and a PhD in interface design, and is currently a professor in computer design at the Massachusetts Institute of Technology (MIT). He is, in short, one of the world’s foremost computer geeks. Mr Maeda concluded that if he, of all people, cannot master the technology needed to use computers effectively, it is time to declare a crisis. So, earlier this year, he launched a new research initiative called “Simplicity” at the MIT Media Lab. Its mission is to look for ways out of today’s mess.
Mr Maeda has plenty of sympathisers. “It is time for us to rise up with a profound demand,” declared the late Michael Dertouzos in his 2001 book, “The Unfinished Revolution”: “Make our computers simpler to use!” Donald Norman, a long-standing advocate of design simplicity, concurs. “Today’s technology is intrusive and overbearing. It leaves us with no moments of silence, with less time to ourselves, with a sense of diminished control over our lives,” he writes in his book, “The Invisible Computer”. “People are analogue, not digital; biological, not mechanical. It is time for human-centred technology, a humane technology.”
The information-technology (IT) industry itself is long past denial. Greg Papadopoulos, chief technologist at Sun Microsystems, a maker of powerful corporate computers, says that IT today is “in a state that we should be ashamed of; it’s embarrassing.” Ray Lane, a venture capitalist at Kleiner Perkins Caufield & Byers, one of the most prominent technology financiers in Silicon Valley, explains: “Complexity is holding our industry back right now. A lot of what is bought and paid for doesn’t get implemented because of complexity. Maybe this is the industry’s biggest challenge.” Even Microsoft, which people like Mr Lane identify as a prime culprit, is apologetic. “So far, most people would say that technology has made life more complex,” concedes Chris Capossela, the boss of Microsoft’s desktop applications.
The economic costs of IT complexity are hard to quantify but probably exorbitant. The Standish Group, a research outfit that tracks corporate IT purchases, has found that 66% of all IT projects either fail outright or take much longer to install than expected because of their complexity. Among very big IT projects—those costing over $10m apiece—98% fall short.
Gartner, another research firm, uses other proxies for complexity. An average firm’s computer networks are down for an unplanned 175 hours a year, calcul
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
The problem with software development does't involve professionalism. It involves economics. Put simply, it's a matter of companies and consumers continually expecting better results, but not always being willing to pay what it takes to get those results.
So what we end up with are shorter deadlines than are sensible or possible to meet, all while trying to accomplish increasingly complex tasks. In order to ship a product, something will have to give. Often times this is only possible by reducing the time and effort spent on testing, or by otherwise reducing the quality and performance of the software that is being developed.
"What I did not say is that thinking is easy."
No you didn't. You said, "Ideas are not the product of labor."
Definition of labor according to Merriam-Webster, just the first/primary definition:
Main Entry: 1labor
Pronunciation: 'lA-b&r
Function: noun
Etymology: Middle English, from Anglo-French labur, from Latin labor; perhaps akin to Latin labare to totter, labi to slip -- more at SLEEP
1 a : expenditure of physical or mental effort especially when difficult or compulsory
Please note: "physical or mental effort". I'm not trying to nitpick. Just disagreeing on our definition of the word "labor".
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
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.
KFG
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
Some of my best ideas have been a product of the closest men get to feeling the pains of labor....."dropping a fat kid off at the pool" as it were.
Many of the "software engineering" textbooks out there, even those written by "respected" authors, are complete trash.
A large number of the modern books suggest UML as a solution. Anyone who has actually employed UML knows that it's virtually nothing but hype. Yes, a UML class diagram may be somewhat useful when demonstrating how existing code is structured, and a sequence diagram may prove helpful in showing the flow of messages between objects. But it's unsuitable when used for the design of a large-scale system. One you get beyond 10 or so classes, UML diagrams become too complex to work with, and are basically useless.
The same goes for software patterns. Many do make sense on a small scale. But then the designers of systems try too hard to use patterns wherever possible, the application becomes unnecessarily complex, and failure is often the end result.
Fred Brooks is one of the few authors who has made any real contribution. Of course, that's because he actually had years of experience working on some of the largest, most important and most widely used systems of his time. Even years after some of his writings were first published, they remain one of the most useful guides when it comes to software project management and development. So while some authors babble on about UML and patterns, we need to listen to what Brooks said. Mainly, we need to realize that the main factor is the people who are working on the software, more specifically their knowledge and experience. Solid developers will produce solid software.
The replies as to what the problem really is are all over the map. This shows the biggest problem facing software developers today: software developers. There's no standardization that's worth a damn in most shops or on most projects. In addition, there are many people writing code who shouldn't be-- survivors from the flush times, when plenty of secretaries and liberal arts majors made their way into the field for the easy money. Lots of these people stayed on, got undeserved respect from business people, and were viewed as experts while others lost their jobs. I think that big business thinks it's got a good chokehold on IT, finally, but they're wrong. Instead non-savvy managers have managed to promote people who are most like them. In addition, without any pressure to improve or conform to standards, most people who begin with rigorous training let themselves slide, through a lack of direction on sheer laziness. The one-programmer rule only seems to add value because the suckage of multiple lamebrains working on the same bug-riddled code, with different bad concepts, being pulled in multiple directions by cheeseheaded managers, increases exponentially.
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.
Even dealing with a high level language like that in Adobe's Director, there are too many unknowns and edge cases and it is not painfully clear just how everything plugs together. Building a structure for doing all the tasks you need to accomplish is also paramount. As I said, "The structure allows you the luxiry to focus on the details". Build the structure.
Cheers
- Zav - Imagine a Beowulf cluster of insensitive clods...
That's another reason.
If an architect designs a building that falls down, he's done.
But there's no accountability in writing software. It's going to be interesting watching what happens when accountability starts being applied to programmers. I can hear the whining already as the incompetents get forced into flipping burgers: "But I'm not incompetent, I just can't write code fast."
Here's a book I recommend anyone contemplating "why is software hard" should read.
People love to ask why we can't build software like we build bridges. Well, we've been building bridges for what? Several thousand years now? I bet if we look back at the first 50 years of bridge building (which is about how long we've been building software, give or take) we'd see similar mistakes being made to how we are trying to build software. In a thousand years or so, I'm sure we'll have enough accumulated knowledge of how to build software that these silly questions of why we can't build software easily now will seem childish at best.
Let's see: the idea is that technology is hostile and hard for humans and the conclusion is that a decade from now everyone with either be digital natives who have no problems or digital immigrants who are learning. Kind'a contradictory.
There is a reason why software takes so long to complete, and another why the 'state of the art' is so damn bad.
Software is an art, but the development of Working software is not, it's an Engineering Science. Software that works, correctly is possible to build, if ones follows engineering principles. Analysis, careful design, and testing at every step in the process.
Software in itself does not fail, it is the process behind the software that causes the software to fail. Poor testing, poor requirements == poor software. A weak link in any of these, and you have shit instead of software.
There is a reason why software engineering (here in Canada) is being taught, it's to correct the weakest link in the chain, the developer. This is the main differnce between a simple programmer (code monkey) and a software engineer. If one applies the correct engineering principles to everything, the quality certainly improves. It took 50 years for engineering to become what it is today, and still structures fail. There is a difference however, in how these failures are treated, and what analysis is done before even the first concrete is poured.
It might take another 50 years before the distinction between a simple programmer, and a software engineer is made, but progress marches on.
"One thing I've noticed about companies is that they try to treat programmers like factory workers. "
Software Factories
But a single lazy or incompetent programmer can make the whole thing impossible.
I'm working on a project now, there are 2 people in a team of 60 that have this problem, and as a result the whole project is designed around what they can't/won't do.
"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.
So thats why all the games these days are just rehashes of old games with one or two new features.
Licensing.
EOF
What?
Are you talking about "Ideas may come in a flash, or evade forever."?
Which is the clue that I'm not talking about thinking.
If you've got a point to make, please do so.
Think.
KFG
If I cut a my way through virgin jungle then those who follow have a path.
And copyright puts in the toll booth.
What?
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.
KirbyHah, gaming programing classes. You won't find one person thats important in the industry that's taken those (grunt-work is ok for allot now I guess). As for your instructors words, that's the EA method right there. You want to be part of that? Games that fail, fail for a number of reasons that aren't because they did somethings that were innovative. Poor implementation yes, but thats not because they did too many new & interesting things. If you poorly implement an idea your going to fail (or at least have a VERY hard time) no matter what.
And we are building the house with molecules and atoms. Even with code libraries it isn't as if one can order a window in a standard size, an 8 foot 2 by 4, or pvc pipe.
Programming is *currently* at a much lower level than construction. It is like saying: "Well, we need some pipe here, so lets find some polyvinyl chloride (or worse, how do we make polyvinal chloride, lets get a chem e and the chemicals and make it) and the tools needed to heat it and shape it into pipe. And we need some wood, so lets go grow a tree, cut it down and mill it." The tree and the polyvinyl chloride are about the best level of APIs, libraries etc. And the code between is at the atom/molecule level.
And then there is the issue of the foundation of the "house" varying by the OS, compiler etc all in very slight ways.
CS/Comp Engineering is making progress, but it is highly complex and as if we were creating the construction industry, but starting it from the basic building blocks of chemsitry and physics level.
I think that possibly one reason that software isn't getting better is that hardware hasn't caught up to software in terms of abstraction.
Why is there a hardware stack with special instructions for supporting pushing and popping data onto it? It's not absolutely necessary.
Why are there certain data types like int, float, etc?
Why is there hardware supported virtual memory? Didn't that start as software? Why didn't it stay that way?
It's because these are extremely useful abstractions over bits. The hardware could just move bits around, but we have stacks and data types to support the fast execution of C-style programs and the UNIX process model.
Herein lies the problem. Until hardware supports more abstractions than just C-style data types and functions, we'll always be coding to that level.
Hardware has been getting faster and faster in terms of raw speed, but in terms of features, it's been stagnant for decades.
How nice would it be to be to have hardware supported garbage collection? This would solve a huge number of problems in the software world.
Sure, you can use high-level languages to get similar results, but there's no unifying architecture that lets them inter-operate easily.
I think that things will get better once manufacturers start to look at other ways than raw speed to differentiate themselves.
If moderation could change anything, it would be illegal.
This 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
"Yes, I am an operating-systems geek. How'd you know?"
The sweet way you said everything.
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.
Are you talking about "Ideas may come in a flash, or evade forever."?
"Which is the clue that I'm not talking about thinking."
If you've got a point to make, please do so.
"Think."
Yup, I'm still clueless. Are you talking about a "flash of inspiration"? If so, doesn't some prior thought have to have gone into the problem? No one has a flash of inspiration without having put the thought into identifying a problem or goal. If so, you still haven't stated how that is not labor. I've already put way too much LABOR into trying to decipher your ramblings. I'll reiterate, if you've got a point to make, do so...without obfuscation.
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
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'll reiterate, if you've got a point to make, do so...without obfuscation.
No.
KFG
Before I listen to another word from someone who complains about what a mess computers are, I want to know: "Show me your desktop".
Running Windows? There's your problem. NEXT!
Everybody knows some footballers are worth a million dollars and others are not worth a fig, but somehow hardly anyone realises that some programmers are worth a million dollars but with some others it would be worth a million dollars to get shot them (see the daily wtf for details).
Sent from my ASR33 using ASCII
No, dumbass. The idea is that within the next ten years, technology will become much more accessible and integrated into our lives, because companies are already beginning to realize there's a world beyond those of you autistic little shits who demand technology be obtuse and difficult to use.
The title is nonsensical.
Hardware is hard, but software is soft !
McCartney fans pay bus tickets. [...] Lennon fans too, with discretion.
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.
I'll reiterate, if you've got a point to make, do so...without obfuscation.
"No."
Hmmm. I could take that several different ways. How about this, I'll take it in the least negative way possible and assume that you have as good or even better sense of humor than I do. That being said, let me know if you're ever in Charlotte NC and I'll buy you a beer.
almann@caro(obfuscation)lina.rr.c(obfuscation)om
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
"Why is there a hardware stack with special instructions for supporting pushing and popping data onto it? It's not absolutely necessary."
Because the FIFO is a general purpose idea.
"Why are there certain data types like int, float, etc?"
Math is useful.
"Why is there hardware supported virtual memory? Didn't that start as software? Why didn't it stay that way?"
Speeding is nice.
"Herein lies the problem. Until hardware supports more abstractions than just C-style data types and functions, we'll always be coding to that level."
Which abstractions?
"How nice would it be to be to have hardware supported garbage collection? This would solve a huge number of problems in the software world."
Ta da!
"Sure, you can use high-level languages to get similar results, but there's no unifying architecture that lets them inter-operate easily."
AST
But if software is at all interesting, it's because no one else has done it before.
;)
Sounds like one of my regular cooking sessions
Out of curiosity, how do you find the jump from business applications development to game programming (even if you're doing it just for fun).
Download free e-books, lectures, and tutorials at bookgoldmine.com
. . .let me know if you're ever in Charlotte NC and I'll buy you a beer.
Help! Help! He's trying to kill me off!
KFG
Software isn't hard, and neither are brains. They are both soft and squishy.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I like the general idea. In C you have the "static" keywork that makes a variable keep their values between calls of a function.
I would not propose an "always persistent" memory, because too many calculations are temporary, but a "persistent" keyword in the most used programming language would be a very nice thing.
However, there is the entire databases thing, they use another paradigm that should be taken into account.
We are Turing O-Machines. The Oracle is out there.
Mod me down for this but this is a true story...
After telling the project manager who was going to hire more programmers to speed thing up his response was:
"well, we're going to try fucking her 9 times to speed things up"
The moral of the story is that the project was 3 years late and i went to work for a competitor.
It is not just the developers actually. On quite a few occasions, I have witnessed project managers not doing their job properly and allowing feature creep at the 11th hour.
". . .let me know if you're ever in Charlotte NC and I'll buy you a beer.
:) If I was trying to kill you off I would never have offered to buy you a beer! I'd have offered you a kool-aid...
Help! Help! He's trying to kill me off!"
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
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
That entire conversation reads so well. :-)
the NPG electrode was replaced with carbon blac
If I was trying to kill you off I would never have offered to buy you a beer! I'd have offered you a kool-aid...
Well that wouldn't work for shit. I don't have a kool-aid intolerance.
KFG
"If I was trying to kill you off I would never have offered to buy you a beer! I'd have offered you a kool-aid...
:(
Well that wouldn't work for shit. I don't have a kool-aid intolerance."
Jim Jones' cult members had a serious kool-aid intolerance.
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
Jim Jones' cult members had a serious kool-aid intolerance. :(
Something I'll bear in mind if I ever become a religous nutter. Now if you'll excuse me I have to go pack or I'll miss my ride on the comet.
KFG
I have to add, that this "labor" doesn't apply to everybody.
You have to be already smart and creative to begin with. More creative than smart, which is harder to find.
We are Turing O-Machines. The Oracle is out there.
Choosing whether or not to go to the emergency room when you have no coverage is hard.
Telling your kids they can't have stuff you can't afford on your waitress salary is hard.
Standing on a crane hoisting icy branches off a powerline is hard.
Choosing whether to take cover or provide cover under enemy fire is hard.
Writing programs is a challenge of the sort not everyone is up to, but it is not hard.
Help stamp out iliturcy.
Try doing advanced math using the roman numeral system (no translation).
The analogy is that programming is today being approached in a manner that is far more limiting then it needs to be.
There are those who claim programming is nothing more than mathmatical algorithims, but it is more as programmers create higher level abstractions to deal with lower level abstractions faster. Sure it can be all boiled down to mathmatical algorithims and even down to binary or machine language but it is the higher levle of abstraction where software is today created.
The science of software has failed or been distracted from the genuine objective of identifying and defining abstraction physics. For it is Abstraction that is the essence of programming, and there most certainly is a physics that applies to our creation and use of abstractions.
We create abstractions in order to simplify or automate complexity of lower level abstractions, down to binary.
The failure is that of not recognizing what we all constantly do, what action constants we apply in our creation and use of abstractions.
Its like doing chemistry before we came up with the understanding to create the table of elements. We didn't understand the underlying mechanics. But once we understood these underlying mechanics, we created chemical megaplants.
Though we would not create software megaplants, in understanding abstraction physics, we would do what was accomplished with teh conversion of math from roman numerals to the hindu arbic decimal system. We'd make programming easy enough that the adverage user would do alot more for themselves, just as the general population was able to not only do math for themselves in teh conversion of symbols used (roman numerals to decial) but were able to do more advanced math then the roman numeral elite accountants were able to do.
Of course the problem is in conversion, as it took 300 years for the conversion to happen. It took 350 years for Galelio to be exonerated....ask the catholic church why... and know why the industry of programming, and regardless of what side of the fence you are on (proprietary or open source), presents resistance to the needed change.
Programming is hard, because the industry wants it to be. So to keep the elitism, social status and pay scale.
Of course social demands weigh in on the change happening. As computers today could not have been created using the roman numeral system of math. It won't be hundreds of year for this change to happen, as we already can't keep up using the lessor/harder route.
Abstraction Physics
The housing and construction business has professional estimators. Perhaps the software biz needs the same thing. However, if one is not familiar with the domain (type of biz), then such can be difficult. Thus, the estimators may need to be industry-specific: fashion software, accounting software, medical software, etc.
Table-ized A.I.
Are you on the same comet with John Travolta and Tom Cruise? Oh shit, nevermind, I don't want to get sued into oblivion.
:)
Have a nice evening.
I reserve the right to think for myself. Others' opinions are optional. Puppy on lap = typos...not illiteracy.
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
With respect to games, there has been too much focus on whiz-bang graphics, and not so much on fun. The funnest games I have played are not very whiz-bang. Darwinia. Lemmings.
Don't get me wrong. Doom3 was great. Half-Life 2 was god-like. Painkiller was probably the most refreshing breath of fresh air in the high-quality graphics world.
"No matter where you go, there you are." -- Buckaroo Banzai
The Gospel according to lolcat
Software is "hard" because big, proprietary, monolithic applications are by nature full of hard-to-maintain code that ends up being lost to oblivion when the project is abandoned, or when the company goes under. In other words, it's a wasted effort, and every competitor needs to recreate it, and make the same mistakes.
The trend of marginalizing programmers and subsequent movement to offshore and outsource has contributed much to making software harder. By locking programmers away in a monolithic "I.T." department, moving development management into separate floors or buildings from their clients, and the actual programmers thousands of miles away, most of the manpower is spent transmitting requirements though a long human chain in one direction and collecting and aggregating status in the opposite direction. A huge amount of software is not "enterprise-wide" and would be better off done by programmers working directly in and paid by the business.
This is true, unless you have been drinking.
So that's why he offered me a beer! But I fooled him, Grandma, I'm a cognac man.
If you think you are loosing your rights, ask your self, has your life been altered since you lost them?
No, because I have lost my right to alter it.
KFG
The problem with the AC parent's argument is that developing software well is actually more efficient (and therefore both faster and cheaper) than developing it using crap like deathmarches and heavyweight processes. Unfortunately, only a relatively small (but remarkably successful) proportion of managers appreciate this.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
~ I am logged on, therefore I am.
That's the shittiest interview I've read in a really long time.
Is "shittiest" the superlative of "shitty"?
I'm glad the author disclosed a raft of biases that make him useless as an interviewer/reviewer for this particular person/topic. I read the disclaimer, then I read more.
"programmers are programmers because they like to program.. and EVERY TIME they will write their own code from scratch rather than using someone else's?"
This article (and book) are useful for exactly one thing:
they confirm the long-understood principle that anyone who names a "law" after himself is a pom[pous, self-loving weenie of the highest order.
Rosenberg's Law?
I'm breaking' it right now, baby.
You make a widget. The widget has a defined interface (ala any OOP methodology). You have defaults, but you let the programmer override the widget's defaults if he wants. This, in turn, means that the programmer can do something like this (and I know I didn't do allocation here. I'm simplifying): [code] main() { int a,b,c; input_widget.load_definition(whatever); // Load a definition from some structure.
input_widget.run(); // Let the user do whatever until he hits "OK"
a = input_widget.get_a();
b = input_widget.get_b();
c = input_widget.get_c();
output_graph_widget.graph(a,b,c); // Or whatever format.
}
[/code]
The end result is something that's simple to write, gives a standardized (relatively) UI, and is not particularly work intensive. C++, ObjectiveC, etc., have various ancillary widget sets that perform this functionality, but I haven't seen a decent widget set that will let me write quick and dirty applications that simply. Granted, I haven't looked in well over a year.
is the human brain is supremely capable at generalizing facts, whilst code isn't.
Most specs are reasonably simple on the initial pitch, it's when questions are asked and development starts that the problems appear and the code grows tenfold in size.
I keep on reading about new coding techniques to reduce deployment time - but the coding technique surely isn't the problem. The problem is that the wonderful brain in your head allows you to simplify stuff - a simplification you don't see until you have to implement it.
Just to summarize, the problem isn't with coding, the problem is how our wonderful brains specify problems.
...if you're stupid.
It's all because of poor design. Design should be 50%-70% of a project, with coding coming only at the very end, to implement well defined things.
Have you read my journal today?
Rosenberg says:
And programmers, as I quote Larry Constantine in my book,
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.
I disagree. Only bad programmers do this. If you have programmers that do this they should be fired. We have in fact dumped a number of these people.
Rosenberg then says:
And the programmer who says, it will be faster for me
to write it, rather than to learn it, is usually correct.
Wrong. The programmer who says this is almost never correct. Rosenberg somewhat vaguely implies so in the following sentences but words it poorly.
The problem is that obscenely obtuse computers are trying to deal with a soft and fuzzy world.
Hooker and madam.
It is *not* manufacturing. If something already has been done in software, buy it. Don't build it unless you have, and be prepared for it to be open ended and expensive. This is basically what part of the article states. Also, I've posted this idea a few times in the past trying to make this same point.
New software is R&D which is why when MS decided to do rewrites in Vista, they were doomed to have schedule slips.
New software is R&D, but managers insist on managing it as a manufacturing process. And so we should not be suprised when the schedule slips, the project fails or the software is crap.
New software is R&D and therefore cannot be scheduled, predicted or budgeted.
And so, I have to ask, a PIM? They are building a PIM? The PIM space is crowded and they are up against MS, Novell, IBM and a host of OSS projects in the PIM/collaboration space. They are going to spend a large amount of time reinventing the wheel and end up in a highly competitive market. I don't see them being able to recapitalize very rapidly, if at all. The R&D will kill them and they will always be at risk of MS giving away an app away for free, IMO.
putting the 'B' in LGBTQ+
1. The pointy haired boss keeps buying silver bullets from vendors that take him on golfing excursions and forcing them down your throat.
2. You cannot plot a gantt chart of something that has never been done
before.
3. The pointy haired boss buys too many tech magazines.
4. The pointy haired boss buys into the whole development methodologies BS.
5. Only 1 in 20 programmers around you even knows what a array is.
6. The same pointy haired boss buys a bunch of expensive silver bullets from some vendors
and has no choice but to implement it or his ass is grass.
Software is hard because I cannot say any of the above without posting as a Anonymous Coward
and still keep my crappy job.
SIGSEGV caught, terminating
wait... not that kind of sig.
Everything was hard before it was industrialized.
You are checking your backups, aren't you?
This is exactly why Computer Science is an experimental science and not an engineering discipline like building cars or bridges.
Problem is, that most managers are under the illusion that writing software is as predictable as baking a cake and can be scheduled thusly. Programmers often buy into this and trap themselves into schedules that are completely unrealistic. Programmers who don't buy-in are labeled troublemakers. The result is programmers who over-promise and under-deliver -- thus the software of today.
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.
Well, guess what. Kapor and his team were very competent developers. There was no economic pressure. There were no "workarounds" to meet arbitrary deadlines. And they were trying to do innovative things, so "dumb users who don't know what they want" can't be blamed either.
And still it is hard. None of the so called Insightful responses here so far have the slightest clue. They are typical responses as if no one has RTFA.
Oh, wait...
rd
... Why hardware is soft? :)
To use the analogy of building a house, you know that you want a foundation. A solid foundation. A foundation that can take the strain of what you are likely to build on it. You do NOT ask prospective house-owners what colour it should be, what material it should be or what shape it should be. That is not their problem and should not be their problem. Those parameters may be influenced by what they want - if they want a ten-storey building, you probably want to think rather differently than if they want a single-wide mobile home - but that is the absolute limit that should be permitted in terms of external input.
When you build a piece of software, 99% of what is written will be invisible to the user. Only the 1% that constitutes the user interface has any bearing on the user whatsoever. So long as the guts are capable of performing the necessary tasks, those guts are your foundation. They are nothing to do with the user and should not be based on the user's requirements.
But they have to be based on requirements of some sort. So, what requirements are they based on? That one is so amazingly easy. You analyze not what the user wants, but what the user needs. These might be the same thing, but more than half the time they will be so astonishingly far off that you'd wonder if the requirements even relate to the same universe, never mind the same person. You then abstract those need requirements, formalize them in some way, reconcile any conflicts (which are almost always because the analysis was flawed) and then convert those requirements into a rigorous specification. No different from any other engineering discipline, except that other engineering disciplines don't have to work in quite the narrow range of tolerances as software engineers.
Once you have a specification, you reify it. You turn it into software. Traditionally, this has been by stepwise refinement - slowly moving the specification from the formal to the implementable and finally to the implemented. Modern "extreme programming" methods work by converting the specification into a test harness (which is a relatively trivial step) and then writing the code until the test harness validates it.
But none of this is new. It's long been said that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization. It is precisely because other engineering disciplines have evolved from slap-dash methods to rigorous techniques over the past 10,000 years that software engineering has attempted to go directly to the inevitable end-result. Programmers should not have to wait until the year 32,000 before they can get a simple GUI to work - although some companies would seem to be heading in that direction. It is true that no major general-purpose software product has ever been "correctly" software engineered. This is not because the methods don't work, it's because companies would prefer to take your money now AND take your money later when the bug-fixed release comes out. Doing things right the first time is so unprofitable in today's world, so programmers don't bother.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Why does this comment make me think of pubic hair?
in other words, your ideas are shit?
Do you even lift?
These aren't the 'roids you're looking for.
Just a side note---you are quite optimistic about Fermat's last theorem if you think you could do it in a lifetime. After all, it took a good number of brilliant mathematicians working over centuries to develop the concepts necessary for Wiles's proof.
Software development is hard because of a misconception that knowing how to program in a particular programing language makes someone a good developer. Just because someone can learn a foreign language (i.e. an American who's native language is English can learn to read and write in French) but it does not mean that person will be able to write a good novel in that language.
I'm currently working towards my Masters in computer science and although I don't intend to ever work as a software developer programing concepts make up the majority of the curriculum. The majority of the graduate program, in computer science, is made up of international students (the university is in the US) of whom most hail from India. After working with these students for some time now I have learned that they obtained their undergraduate degrees from India where computer science is taught in theory. This means that they got their degree without ever touching a computer. Combine that with the fact that they have never owned a computer themselves makes me doubt the quality of their education. For those of you that know some C++ you will understand their level of knowledge when I say that they enter the program without understanding the concept of pointers (dynamically allocated memory instead of compile time arrays), structures, or object oriented programing concepts. Luckily many of these students do not make it past the remedial courses of the graduate program but most of them switch to the IT program under the business college of the university. Unfortunately I am sure many of these students go on to be programmers in their country where there is a big demand due to the trend to outsource coding projects to their country.
I have spoken with other students in similar programs at different universities and this seems to be a widespread scenario. So with people that barely understand the language they are programing in are being asked to write programs for consumer use. It seems that very little time goes into educating students on how to program. Here I am using the word "program" to mean given a problem utilize one's analytical skills and artistic ability (yes programing takes artistic ability) to conceive a solution and write it in a programing language in such a way that the language compiler and linker produces an executable program. With this in mind you add the fact that virtually no effort goes into teaching people how to move beyond this basic level of understanding of specific programing languages to a point where any competent programmer would consider them to be fluent in the language they are developing in. Would anyone buy a book written by someone that is not fluent in the language that the book is written in? I think not.
Beyond the fact that the majority of programs are being written by people who are not competent, by any standard, is the fact that programming is not just an application of knowledge of a specific language but an abstract concept that is created from the individuals understanding of the problem and their ability to conceive a solution entirely from within their own mind. This is where the artistic ability comes in. If you give 100 people a problem and ask for a solution in the form of a program you will get 100 different solutions. Out of those 100 people only a handful of the solutions will meet the standards of what could be considered efficient coding.
Consider that the programmers that I am speaking of here are people that entered into a post graduate computer science program. These people do not make up the majority of programmers out there. What makes up the body of the worlds programmers are people that have not attempted to progress to this level. Most enter the workforce after receiving their undergraduate degree and many have not received any higher education at all. It is my belief that aside from what can be taught to an individual programming requires an inherit ability within that individual for them to be able to produce what I would call quality code.
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
Why developing good software is hard, the cartoon. and the spin-off Project Cartoon.
Perfect is the enemy of done.
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.
The article link appears to be broken, I really don't get why people find managing software projects so difficult, Programming is much more an art than engineering.
For example in electrical engineering, I've built a design board I knew what signals I wanted generated, what I wanted doing to them it was something easy to quantify, am I looking for a microcontroller or FPGA? Which is cheaper, which specs are capable of doing what I want. I have definitive specs (which rarely change) and lotsa fixed parts.
Software Programing is filled is many intangable parts, many people find programing languages like C and Java wierd and very difficult. As a result me and a friend could finish working programs in class, go through a few class mates code, help them understand the difficult bits and get them to see where their going wrong before bunking off to play pool. I'm not a great programer by any means, so its easy to see that like artists, great artists can do fantastic stuff in seconds which a poor artist could never do. I've had to do this 'Software Project managing' module in university and so far every solution has been an attempt to bring engineering style of management over to whats really a artisic discipline. Why does no one want to run a software house like a fashion house, or a comic house? Yes engineering principles need to go into the design, but Electrical/Mechanical/Civil is mostly dealing with materials, Software is mostly dealing with people, like art.
I'm not trying to devalue software engineering, its a field I'm very interested in but I'm amazed no ones realised that you can't manage the project like an engineering project, you can design it like an engineering project (and you should) but people are this annoying highly unpredicatble thing, often prone to moody tempers while they look down on others because they don't get how their disicpline is so important as they labour into the night talking about their genius, wait I am talking about artists here arent I?
Programming is one of the jobs where you are routinely facing the complexity barrier (the point where the number of factors to consider exceeds the human processing capabilities), that's why it's hard, it is and it will be.
From Godel we know the limits of formal systems, the best reply to this limit was Turing answer (paraphrasing) 'Errors are the natural answer to determinism'.
What's in a sig?
1) Social-economic processes impose changing biases to the current paradigms of software development. This leads to a biggest reason of code not being reused and ever-changing development environments.
2) As usual in the bussines world, the driving force is only the first derivative of the cost. Local minima can be quite stable. Morover the local minima are deterimed in a way wich seldom integrates over a long time (e.g. support).
What i mean is: Todays product lifecycle is *assumed to be* shorter than ten years ago. Tell to somebody today that there will be a phase of a few months with no visible results in terms of the final product will yield a different response that ten years ago. Sadly this means that porting code (which, if you do it right, takes most of the times longer than developing "something" with a "state of the art" Development environment) to be usable on a new platform is underrated.
However, old code very often has no semantical problems any more and all these "small bugs", like implementing a special semantic for a certain parameter value or realizing that a certain database lookup will fail under certain circumstances because of some kind strange constellation happening seldom but on a semantical level, are fixed.
Not Funny - TRUE - I an NOT a Google SHILL !!
Is "scope creep", caused mainly by incompetent project managers.
---- Booth was a patriot ----
It's true I tell you, feller at work's next door neighbour read it in the paper.
Much more than any other domains in the industry, even regarding arts, at least as much as drawing and writing, definitely more than music and even mathematics for more academic studies.
The main consequence of this being that people good at computer science tend to stay at the lowest possible level of the decision chain of software building. That is why big, or more simply established, compagnies tends to produce the same software, again and again, or to stick with mediocrity.
That is why startups are generally better are inovation and why the myth of the "little genius behind his keyboard" is so a die-hard legend: first because it is true, people without social or contractual constraints tend to produce better software,
second because it serve managers: the more you are good at computer science, the closest you are to the next 16teen kid who
television has talked about, so you cannot be considered seriously, can you? So you stay at your place and the manager, which comes from a "better" high school than you, as all the managers in the compagny, all appearing to come from the same school.
It is not that software is hard by itself, it is like anything else: you have what it takes to be good at this, or you haven't, it the way industry tries to handle it which makes it appears so difficult.
I use tools like this and this in order to to tease out the information needed. UML is much further down in the process.
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.
That said, I don't think many software projects would be given enough money to achieve this anyway, because the consequences usually aren't important enough (no-one's life is on the line).
I work for a commercial aerospace company, you insensitive clod!
The page with the article goes into an infinite reload loop if Salon's cookie is disabled, demonstrating that Salon can't write good software.
My response to this article on the third page of letters:
- flossimpact.pdf
Haven't ANY of you people heard of FLOSS?
Software development is NOT hard. The closed source development model is. I refer you to a recent study on the economic impact of open source software that was recently published in the EU. The URL is:
ec.europa.eu/enterprise/ict/policy/doc/2006-11-20
While the entire 287 page report makes for fascinating reading, I'd like to direct your attention in particular to pages 48-53. Read that and tell me that software development is hard. Clearly, it's not when it's managed properly.
The right link for the article is http://www.salon.com/books/int/2007/02/03/leonard/ . The other one leaved me in a "click-here" kind of redirect page.
Er Galvão Abbott - IT Consultant and Developer
Actually, every instructor I've had works in the industry. Not *DID WORK*....but *WORKS*. Classes are at night.
Ahhh getting use to being burnt out and not having any kind of social or family life to speak of early on are you? Should prepare you well for that industry. Good little code Monkey.
This is NOT something to be proud of. It is NOT a good thing. It will not leave you happy and satisfied. If you _HAVE_ to work long hours or study till the early hours of the morning for a short period of time, that's usually doable without too many adverse effects. Try it for too long and trust me from someone who worked and commuted for 12 hours or more a day and then went back home to work on a Masters, it'll leave you isolated and/or with health problems.
I've always found it amazing that certain jobs required working ridiculous hours when you can't be at all efficient and it plays havoc with the rest of your life. I guess I don't mind as much that game developers choose to put up with this, but doctors work equally stupid hours. I'd rather have some code messed up than have my life messed up by a doctor who made a bad diagnosis.
These posts express my own personal views, not those of my employer
I wrote about this subject recently as well. I agree that programming is hard, and programming for other people is even harder. I also agree that programming is _not_ an engineering field ... yet. As a professional programmer, I believe that we can and are advancing the state of the art in computer science, so that one day my electrical engineer buddy will be able to say "hey, that last application you wrote was a marvel of engineering." One day my friends ... one day.
My article explains it a little better.
"Engineering is the application of math and science to create something of value from our natural resources." quote from
Dan Lash
He is a troll... That stands to reason that:
/. rules), his "girl-friend" is also a troll.
1. If he had one (remember
2. Trolls eat flesh. He has to regrow it every time she does.
3. Ouch! (Not profit!)
****
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!)
****
This has nothing to do with the design or creation of software. It is poor contract management, and poor Systems Engineering. Did your project have a requirements manager? Did they write a Concept of Operations document, followed by a set of Use Cases? Did they agree these with the customer in writing? No.. and you're blaming this on "software being hard"?
Half the problem is that "Computer Science" graduates are not taught to design anything like an Engineer. They can write code, and indeed this is what they are most inclined to do. The day after the customer requests a project they are in there writing code already, and this is a terrible way to start a project.
NASA tried this approach in the 60s and 70s as the started doing larger and larger projects, and found that a little bit ($100k) of Systems Engineering up front can save them a lot towards the end of the project ($100M).
The answer is that writing software isn't hard. No you aren't "breaking new ground" by adding a feature that noone else has, because someone else has already written something very similar in another application. At least, you aren't breaking new ground in terms of software. Just because you didn't bother to read a book on algorithms, doesn't mean your depth-first-search is original.
Computer Science Degree - 3 years (in Australia), and about 20 contact hours per week.
Electrical Engineering Degree - 4 years, and about 30 contact hours a week.
Limiting the scope of the new idea works in short stories, whose length signals a tight focus. In novels, the available room is there on purpose to explore the connected suite of ideas that result from the *setting*.
Although this next remark is a business comment, I think it holds true for programming. I work hard in my company to reduce the "cheap glory" factor of people understating the time involved. This happens for all kinds of psychological reasons. "It's very simple, and I want it done now!" causes real expectation problems.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
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.
HAHAHAHAHAHAHAHAHAHHAHAHA
Sorry, but do you have any idea how dumb that made you sound? Anyone who says something like that and isn't a world class expert in modular forms has a) absolutely no idea of what "proving Fermat's last theorem without using reference material" would actually mean in terms of effort and talent required, and/or b) delusions of grandeur of a magnitude baffling even to Slashdotters.
Most likely, there was never an individual in the history of the world would could have done what you claim to be "highly likely" to do, unless he already had an immense knowledge of the fields that he would otherwise would have to refer (which is why I made the possible exception of the world class expert). Wiles himself couldn't even have done it hadn't he been an expert in elliptical functions. Basically, what you claim to be able to do with very high probability is to, within the rest of your life reproduce some of the best work of Hilbert, Noether, Galois, Shimura, Abel, Frey and Wiles. That alone would make you one of the greatest mathematicians in history.
If you had said that you might be able to understand Wiles' theorem if you spent your whole life studying it, I might have agreed with you. Might.
You're correct, that is a misstatement on my part, I meant that it was highly unlikely, not a double negative that I did write.
Oddly enough, lots of people are unhappy with Wiles's method. I believe a number of people are attempting to prove it using a purely number theory approach. What Wiles ended up proving was a vastly stronger statement, the result for Fermat's was a corollary (I also think that Wiles became an expert in Elliptical functions specifically to make this proof, he started in a different area according to what I'd been told). I wouldn't be shocked if several more simple and straight forward proofs come out in my lifetime. For a long time the proof for the fundamental law of arithmetic stood unproven. Now it's a standard proof in every number theory book. As I recall, I had to do it for a test.
Kirby
That's a joke, son. Maybe if you expended some mental labor you'd have an idea what he was talking about.
In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199
.. until the release of Vista that is.
Now, its so easy to get on the internet, do your hotmails and digital photos, and connect with others in new and unexpected ways.
Its all about the WOW, and thankfully everything is now so much easier - including software development programming.
And its the existence of people that swallow this sort of shit that contributes to making software hard. These sorts of people, when they involve themselves at whatever unwanted level in the process of developing software, turn out making the whole game look so much more difficult than it really is.
And then one fateful day when the mangled bastard children of their best creative efforts needs to be interfaced with - then yes, at that point in time, software development truly is a difficult thing.
The factory ideal is what people want, but programming is happening closer to the nano scale. It's only in the past decade that people have started building things using something approximating molecule-at-a-time instead of a atom-at-a-time level tools. Our debuggers can show us the bits moving around, but trying to debug a crash on something like Vista involves tracing through something like a car wreck happening in real time with a microscope and finding out a certain pin sheared off because it was put in wrong. We work at such a low level that it's hard to see the big picture and realize the design has square wheels and will never roll no matter how much we polish them.
You're correct, that is a misstatement on my part, I meant that it was highly unlikely, not a double negative that I did write.
In that case I apologize for the snarky tone.
Oddly enough, lots of people are unhappy with Wiles's method. I believe a number of people are attempting to prove it using a purely number theory approach.
I think most of those are best referred to as "cranks." To the best of my understanding the consensus in the field is that no other kind of proof seems even remotely possible at the moment. Of course nobody could say with certainty that such a proof is impossible, or that it couldn't be produced at some point in the future. But I don't think there's any more reason to expect a vastly simpler proof of this particular theorem than of any other.
I also wonder what you mean by "purely number theory approach". Elliptic curves, galois theory etc are very much parts of the standard number theory toolset these days. If you mean something like "theoretically within the reach of Fermat" I think you will be hard pressed to find even one number theorist who agrees with you. There is a simple proof which almost works, but not quite. It seems likely that this is what Fermat had discovered, and that he simply didn't spot the mistake.
What Wiles ended up proving was a vastly stronger statement, the result for Fermat's was a corollary
True, but irrelevant. Math is full of particular cases which seem to have no simpler proof than that of the general one.
I also think that Wiles became an expert in Elliptical functions specifically to make this proof, he started in a different area according to what I'd been told
That's incorrect. Wiles wanted to make it his thesis topic when entering grad school, but his advisor talked him out of it, by convincing him that it would ruin his career the same way it had ruined countless others. So he chose elliptic curves instead. It was really pure luck that he chose that topic -- it was only about a decade later that Ribet demonstrated a link between FLT and the Shimura-Taniyama conjecture.
I wouldn't be shocked if several more simple and straight forward proofs come out in my lifetime.
As I said, it's certainly possible. I wouldn't be shocked either, but I would be pleasantly surprised.
For a long time the proof for the fundamental law of arithmetic stood unproven. Now it's a standard proof in every number theory book. As I recall, I had to do it for a test.
I assume you mean theorem, not law. However, I'm not sure that with "a long time" you mean "until the first real mathematician in history tried to prove it", but that's about as long as it lasted. The first known proof is due to Euclid, more than two millennia ago. But now I'm being snarky again -- I understand what you mean, and I agree with the sentiment. I did it on my abstract algebra exam too, and I'm certainly no Euclid.
When you look at the past it is going to seem like there was more originality innovation because you're just seeing the highlights. Nobody remembers all the crap between the interestign stuff so it just SEEMS like the past was better. Also keep in mind that you were younger then and to you the whole idea of video games was probably pretty new so even the evolutionary changes kept you entertained. Personally, I can barely play video games anymore. Not because I dont' want to. And not because I don't have time, but just because the novelty has worn off. As a kid I could play the same damn game (with a new title) over and over again and stay interested. But now it just bores me.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
The 1st reason is that the domain of problems is infinite. In all the other engineering fields, like house/car/bridges/whatever construction, the domain is finite. Software is like building a house with the capability of using all its facilities in all possible combinations and with open slots for room expansion.
The 2nd reason is that mainstream programming languages are bad. They are too verbose, they do not allow for expressing the problem at hand concisely, they do not catch most common logical errors, they don't allow WYSIWYG interactive incremental development.
Hmmm, I'll have to talk with my number theory professor for the details. He's the one who told me that Wiles attacked the problem for a long, long time and at some point gave up his original approach because he realized that for precisely the reason that his original approach couldn't solve it was precisely the reason the new one could. Maybe he didn't switch at as basic a level as I thought.
Hmmm, I'd always been told that Gauss was the first to prove the fundamental theorem of arithmetic. Ah, Wikipedia says that the first full and correct proof was by Gauss, while Euclid had "essentially" proved it.
Kirby
Assemba?...assemboo?...Asssememblee?....ok, what are you talking about?
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Teach Yourself Programming in Ten Years
i ghlight.html
http://norvig.com/21-days.html
Fred
http://all.net/books/IP/evolve.html
GNU Source-highlight 2.5
http://www.gnu.org/software/src-highlite/source-h
~hylas
Yes, I agree, its so unfair that people who are willing to sacrifice and work hard make out better than those who want to be lazy.
It never ceases to amaze me that liberals berate those who work hard and succeed.
Truth is, its none of your damn business whether or not this guy has a social life. If he wants to spend his time learning how to write games and then work in an industry that demands hard work and dedication, its no skin off your back.
Don't know why I even bother to reply to an AC, there's a reason they're normally below my threshold.
Firstly, I didn't say it was hard. I was describing my reasons that I find from experience in the industry as a whole that software is often LATE. Learn to read.
You must have gone to some two bit Uni then to get your CS degree. Because even when I got my degree software engineering was treated very seriously, and those were the days when it was just getting off the ground. These days most of the developers I know can rightly be called Software Engineers.
You don't seem to have much experience with the way most software is written these days. Possibly because you have only been in the industry for a short time (3 years CS == a novice). Take a read of "Death March" by Yourdon and see what he has to say of bleeding edge technology.
In 20 years of software development I have worked for companies that had good management and others that have bad. The issue I mentioned about the 24 hour design change ... when a client asks something and the general manager tells you to do it or find another job then the requirements etc don't matter. Too many companies function that way. And in fact, while I am on a roll, almost all of them were engineering firms. Engineers, generally, make the worst software developers, picking up code written by engineers, many of whom I regarded as extremely smart, is painful. Bad design, bad coding, poor documentation, unnecessarily complex. Though the documentation problem is universal.
Bitter and proud of it.
Personally I think that as long as I have never done it before, it's interesting. It's how I learn.
remember to loot and pillage before you burn!