Why Software is Hard 409
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."
Product managers... (Score:5, Informative)
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.
Re:Ah! The great unknown... (Score:5, Informative)
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
Primary problem: Playing by the rules. (Score:1, Informative)
No Silver Bullet (Score:5, Informative)
No Silver Bullet: Essence and Accidents of Software Engineering [wikipedia.org]
Because people forget experience (Score:4, Informative)
This author had to discover Fred Brooks after he'd started a career of big projects. TMM should have been in his school curriculum.
Re:Ah! The great unknown... (Score:5, Informative)
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
Re:It needs more professionalism (Score:5, Informative)
I get requests like we need a program that users can run from the web that shows them if batch scans are in balance. I am then left to resolve on my own things like:
*What is a batch scan
*Where can one find a batch scan
*What does it mean for it to balance
*Can the thing just print a big Y or N in size 48font on the screen or does it need to detail something
--Then comes the anticipatory stuff
*Is the user going to expect to be able to correct an in blance
*Now that I understand what a batch scan is *maybe* I see all this other stuff should I also report on those things
*etc
People like to expect programming to go like engineering or architecture. Its not the coders don't want to apply discipline to their craft its that they can't. Nobody would dream of approaching an engineer or an architect without a pretty good idea of what they want to do. That is not to say the professional is not going to have to help them work out most of the details but the basics are going to be pretty clear. Imagine if I sent a request to an Architect asking for a "Structure that will be used by people." and gave no other information. I really doubt I would get a call back.
You can argue the PAs are not as good as they should be about requirements gathering, but I think there could be much more professionalism on the part of requesters as well. Its a waste of my time and theirs when they engage me as a developer before they have put even the most basic thought into what it is that they want. Some of this stuff is really esoteric and I understand that I will have to help them figure out how to solve the problem. I do feel they should know what the problem is.
Re:Not to take potshots, but (Score:5, Informative)
This is a point I've come to also after 72 years, the last 35 or so of it coding this and that although not much recently as I seem to be fadeing into the dim sunset of SS mentally.
When working in assembly, then it may be that one person is the optimum number of coders as I've done some never before been done stuff in assembly several times in the early years, sometimes with hand assembly (on an 1802 board) where you look up the nemonic and enter the hex equ in a hex monitor. It took me about 6 months to fine tune about 3k of code, but it was still running 12 years later when I last checked in at that station. And still saving the station 2-3 man hours a day and giving them a better air product at the same time.
But for a higher level language, I think 2 can be more productive, particularly when one knows what he wants to do, and the other knows how to do it once its properly outlined. Many times the coder himself is simply too close to the code to see the job it has to do, but the partner in turn has a good idea of what its got to do. The genesis of at least 2 fairly well known amiga programs were from the mind of a younger man in another dept at the tv station, and he would hack up what he thought might work but didn't, but once I knew the requirements, the final code more than likely came from my keyboard. He had the imagination that I lacked, possibly due to my advanceing age, and was in turn concentrating on his job's duties which I wasn't always aware (I had other responsibilities too) were being done at less than optimal methods. We sure made a good combo crew though.
I have NDI how many man-years in in vista right now, but I dare say it is a substantial investment in both time and programmer salaries. I'd also wager that at least 75% of any one programmers day was spent conferring with other programmers as to the best way to do it, and get it done within the generally immutable confines of the
As for re-using known good code ideas, or a 150 line snippet here and there, it is to be encouraged at every staff meeting, re-inventing the wheel is not good use of his time and as others have said, only serve to intro new bugs that then have to be run down and fixed. Programmers really should get over the attitude that I can write it quicker, and spend more time reviewing older code to see if it can be recycled. There is much knowledge in 10 year old code thats still in use everyday.
Will my little treatise make any difference at the end of the week? Donbesilly, This is after all,
--
Cheers, Gene
Re:Becuase People don't know what they want! (Score:3, Informative)
Secondly I think people know more what they want when it comes to buildings because the options are more restricted. In software there are no restrictions on what can be built (although you can run into performance restrictions).
Thirdly you can see and touch a building.
It's about people (Score:4, Informative)
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.
darn customer wants and needs (Score:5, Informative)
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.