Slashdot Mirror
What Makes Software Development So Hard?
lizzyben writes to mention that CIO Insight is running a short piece that takes a look at why the rocky culture of software development continues to exist despite all of the missed deadlines, blown budgets, and broken promises. From the article: "I was not really looking or thinking about big software projects. I was just coming out of my experiences at Salon, where we built a content management system in 2000, which was painful. I was one of the people in charge of it, and when the dust cleared, I thought, I don't really know that much about software development. Other people must have figured it out better than I have; I must go and learn. So I started reading, and talking to people, and realized it's a big subject and an unsolved problem. And the bigger the project, the harder the problem."
Writing the code from a good design is easy. It is creating a good accurate design, capturing all the requirements accurately and ensuring the end user's expectations are correct.
Anyone can write a book. But, writing a book that's *GOOD* and that people will want to read is an entirely different matter.
Computer software is no different.
Good software takes time to develop. There is sometimes a tendancy to set unrealistic goals and when they aren't met the people in charge feel let down.
It isn't. Haven't you seen them, all they do it wave their hands around and look silly. That's the point. Everyone thinks it's a breeze when it isn't, so everyone underestimates everything.
The reason it's hard is because we are doing the impossible, at least if you had asked someone 50, 20, or in some cases even 10 years ago. Solving previously impossible problems requires quite a bit of innovation and novel thinking. But, it's better than it was decades ago, even if it is difficult. What we need to remind people is that even with fast computers, the problems are still difficult to solve.
Also, automating tasks that we used to perform ourselves is also difficult. It's one thing to walk and chew gum, but another thing entirely to precisely describe the mechanics of doing so. (One is very easy, the other requires creating precise models of how things work, a very hard problem).
What Makes Software Development So Hard?
Simple. The current state of technology in regards to human imagination makes it many times easier to think up of good ideas or improvements for computer software than it takes to create or implement them. Thus the requirements for developers are often made by the ones with the ideas with no idea of the costs (in terms of time or money) involved in making those ideas a reality.
Joe Sacks says "Gee, it would be a great idea of our flight tracking program also tracked fuel usage and recommended fuel loads to minimize weight on subsequent flights". See? It only took Joe all of about three minutes to think that up. He figures that a reasonable amount of time to implement this idea is one or two days. After all, those "computer guys" are pretty smart and can "do anything".
Two days later Joe receives a report that the "project" is over budget (needed to check with the FAA on this one, that cost money) and overdue.
Sure, you could just say that these problems need good project management. But seriously the problem is that these "problems" are not considered worthy of project management. It only took Joe three minutes to think the idea up...why should he hire a project manager for *THAT*. It's not like he's building a new hangar.
What makes software development so difficult for me in my particular case:
1. Requirements are not clearly defined
2. Requirements that are defined change constantly
3. No existing documentation on the system I work with
4. Outdated technology (Not a big issue, but many things are just easier to do with newer software)
5. The sales department sells features that do not exist, promise a date, and do not consult IT at all about the feasibility or time estimates
4 out of the 5 things I have listed above have to do with bad information / lack of communication.
Love sees no species.
When you've contracted an engineer to design a bridge, and you want to make several large-scale changes to that bridge, the engineer will come back and say "If you want these changes done, this is how long it will take. If I don't have that much time, I can't make the changes".
In fact, I'd go a step further; software developers tend to say "This is how long it will take to make the change, and this is how long it will take for me to hack something together." Bridge engineers don't say things like that. They don't put that "hack something unsafe together" option out there on the table, and neither should we.
I think one of the biggest problems in our industry is accountability. The engineer would never put the unsafe option on the table, because the engineer knows he'll loose his license and go to prison if the bridge collapses. With software, on the other hand, we just expect our customers to deal with the fact that it fails, and we behave accordingly - and unprofessionally.
... of all the hot babes running around the offices in miniskirts giving massages that make it tricky to type. That, and the martinis that keep spilling in the keyboard. Combine that with the constant parties, sailing trips, ski trips, etc and it's a wonder anything gets done.
.com bubble anymore? Glad I left software.
What's that you say? It's not the
Well, if you wanted to get really technical about it, the conductor's work is mostly done before the performance, so that any reasonably proficient orchestra would be able to do a reasonably good run sans the conductor.
Conducting, however, is a lot harder than it looks, especially during rehearsal. It requires the simultaneous processing of the score (possibly twenty plus lines going on simultaneously), time (not so easy once you get into funky metric changes), expression (precisely what the conductor is all about) while keeping track of mistakes that happened during the piece even though not stopping immediately. It's extremely easy to see when a conductor is inexperienced, boring, or hasn't looked over their music properly.
For conductors of student groups, they also have to keep the members of the ensemble engaged through tasteful storytelling while not completely going off tangent, they must be extremely creative in figuring out how to get their point across, they must be careful not to over-rehearse a section, etc etc etc.
Ask any marching band student turned drum major. Being a good musician does not mean you'll be a good conductor, and a more generalized notion is the core meaning of most of the other analogies offered by Slashdotters around here.
In that case, you have essentially proven that you have no experience with large software projects. Even if everybody is qualified for the job they are hired to do, and are enthusiastic about the project, and doing the things they are supposed to do, things just don't work out right at first try. Or second try. Or third try. Or... you get the picture. And then, when that problem's finally done with, you have 7 new ones, where at least 3 of them are total show stoppers.
It's of course easy to start pointing fingers at people. That guy is an idiot. The management has no idea what we are doing. Writing documentation is killing my productivity. I had to rewrite this assholes code since he didn't follow my favourite bracing style. And so on... The point is, the guy you call an idiot probably knows three hundred times more than you about fluid dynamics, which is what all the project is about. Management isn't supposed to know what you are doing, they are supposed to handle budgets, equipment, hiring, firing, etc. And the last two are kind of obvious...
Software development is hard, because it's not a solved problem. You don't build software the same way you build buildings. There are no rigid rules to follow, no best practices that can be universally agreed upon. The purpose of each new software project is to solve (a) problem(s) that has never been solved before. And because of that, there are great uncertainties involved. You can guesstimate a lot of parameters, but eventually, some of the unknowns are going to bite you in the ass. (As Rumsfeld said: There are known knowns...)
Not exactly an easy person to work with, are you?
But while stereotypes persist that programmers have no people skills, you forget that many business people don't either.
Just ask yourself: how many effective, people-oriented bosses have I ever had? If your answer is "not many", you're not alone.
I've been software engineering for over a decade. These are a few observations I'd like to share with managers:
--- "We've always been at war with Eastasia."
...that software development needs to have a team of programmers who are talented and competent, and a project leader who knows his people and can effectively lead and manage both the team and the project... and a corporate culture which doesn't treat its people distrustfully like a bunch of indentured servants, then they can write good software and get it done in reasonable amount of time. Getting and retaining a team of very good talented and experienced programmers is very difficult and expensive however since most development firms are cheapskates and not only do not pay enough, but treat their people like dirt, binding them under all kinds of bullshit NDA and non-compete contracts, poor work environment with noisy cubicles or "bullpen" office areas, not empowering them with latest technology workstations and tools, etc. The software development company that teats its programmers golden is the rare exception... the exact opposite "sweatshop" like I described above is generally the norm, as I've seen it in my 20+ years in the biz, hence you usually get kids right out of school as entry-level positions doing the bulk of the development. The best cream of the crop programmers have mostly all quit programming years ago and now are all sitting in management positions and programming no longer.
A good orchestra conductor who is in front of a bunch of rank beginner inexperienced musicians will not be able to make very good sounding music. You get what you pay for.
Herding cats is hard because you are using the wrong management technique. You herd cattle (and sheep and goats and pigs etc.), you do *not* herd cats. Cats, you put them in the general area of the mice and let them do what they are good at. Micromanagement of cats is a losing proposition.
putting the 'B' in LGBTQ+