Of course they don't work. You expected something else?
Why don’t software development methodologies work?
191–200 of 201 posts
Re: Why don’t software development methodologies work?
#192Earlier quoted context omitted.
As an electrical engineer who briefly flirted with computer engineering, I had 4 semesters of continuous math and 1 semester of discrete math[1]. I also had classes like linear systems and electromagnetics where I had to actually use continuous math heavily. While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have fo…
As you say, continuous math (to my mind, calculus, diffeq, and linear algebra; anything involving reals) is necessary for some problem domains. But accounting is necessary for some problem domains as well. And molecular biology.[1] But if I get worked up into a good froth, I can make a case that software development is applied formal logic or applied abstract algebra (or both). I don't believe you can do professional…
I must admit to ignorance of Weinberg's books and other writings. My interest is piqued now, though.
That said, based on your second statement nearly all scientific and engineering programming would not qualify as "professional software development". The code I worked on had little to no discrete math or formal logic in it. There was not an integer to be found save loop counters and array indices Do you not consider an (electrical engineer | mechanical engineer | physicist | molecular biologist) who can code and spends the vast majority of their time writing production code like this a professional software developer?
Re: Why don’t software development methodologies work?
#193They work, but you still need very capable people (developers, managers, product owners, etc). Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
Depends on the size of the team. If you have a 5 or even 10 person team, then maybe. If you have 100? You need methodology. Once you break a project down into subcomponents that interact, you need to coordinate release of any changes to interfaces, so the work of one team doesn't break the work of another.
I still think it is the capability of the people what makes the difference.
I actually have had the experience of leading a team of 50 developers in a 120 people project. We all were the new on the project and didn't know each other, I basically picked the most qualified 7 developers and formed teams. We broke the project into modules and look for smart ways to work and not stepping over each other.
Re: Why don’t software development methodologies work?
#194Earlier quoted context omitted.
How else do you characterize an industry that seems content to re-learn lessons of the past over and over?
1) Industries don't learn; people do. We have a lot of turnover and growth in this industry, so a lot of new people. 2) Although there are high points of genius we may never reach again (Turing, etc), we are making progress. Software today can do things hardly imagined a few decades ago. 3) Part of how we make progress is to try "unlearning" things; throw out conventional wisdom and try something "crazy". Maybe it wi…
I am against a general ignorance of where the industry's been, which manifests as a refusal to learn basic software engineering concepts that are laid out in a book like the Mythical Man Month. Seems like every new medium (such as the web) starts with masses rallying around a figurehead who proclaims "this time it's different! We don't need any of that engineering stuff!" A few years later, they do.
This trend of anti-intellectualism is worrying. I doubt it's new -- Dijkstra had similar sentiments -- but the worst part is the developers who seem to enjoy being ignorant.
Re: Why don’t software development methodologies work?
#195It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…
Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have…
Do you expect to get estimates of outcome from stock market traders? They do their thing and you gain and loose according to external factors.
But seriously scrum with concept of velocity and estimating size of tasks is the best approach I've seen. That's if ou want to ask programmere at all. Preferable way would be to predict the duration of the project scientfically from metrics gathered in the past (of not only the programmers and projects but also the environment they operate in).
How can a programmer estimate when project will get built if he doesn't even know if anyone actually cares enough about it being built to actually decide what the software should do?
Re: Why don’t software development methodologies work?
#196Earlier quoted context omitted.
How else do you characterize an industry that seems content to re-learn lessons of the past over and over?
It seems like almost all professions have a body of knowledge. Software Engineering doesn't. Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.
Actually, there are surprisingly large and persistent differences between hospitals in their complication rates for various surgeries. It is fueling a debate about how to evaluate them and how to promote the methodologies of the more effective places. Not really all that different from the software industry.
Re: Why don’t software development methodologies work?
#197Earlier quoted context omitted.
Having read "the mythical man-month" I came to conclusion that majority of the problems we have today were discovered an described by the 1970-ies.
The majority of everything in software was discovered by the 70s. Since then we have been reinventing the wheel every 5-10 years on better hardware.
I don't think hardware has anything to do with it. I think the most important factor in this evolutionary cycle is that every 4 - 6 years, new Computer Science/Software Developer STUDENTS enter the market, spend a few years catching up, and then trying to re-invent everything. Rediscovering the territory that they'd not really learned that the industry had already proceeded through at much greater pace than Academia.
Re: Why don’t software development methodologies work?
#198Earlier quoted context omitted.
It does, and it has for quite some time: http://www.computer.org/portal/web/swebok
OMG. I just hope you are being sarcastic. That's everything we are complaining about right there on the index.
No sarcasm intended. You don't have to agree with SEI or IEEE, but the complaint was that there wasn't an organized body of knowledge. My response was to show that there is.
I'd be interested in knowing what you find so objectionable about SWEBOK.
Re: Why don’t software development methodologies work?
#199The author seems to answered his own question if you pull out some key points and examine them in a logical way:
1. Software development was tightly controlled in the 70's through a hierarchy of management (project managers, business analysts, senior programmers).
2. Today the hierarchy is gone, reduced to “team leads” and “scrum masters” with no real authority or control.
3. Today programmers left to themselves often adopt or create methodologies stricter and more filled with ritual than software development in the 70s.
4. Today he often gets involved in 1 or 2 people projects that have so much process and “best practice” that nothing of real value gets produced.
5. What makes software development work is “conceptual integrity” or common vision or that feeling working on a team where everyone clicks and things just get done.
6. He doesn't understand why he had that feeling more in the 70’s than now.
Well if you follow the logic, what is missing? The hierarchy of management. Which he seemed to blame for the original reason why software development methodology doesn't work.
I hate to admit it, but maybe the hierarchy of management added more value than we gave them credit for?
He sort of suggested finding that “feeling” in a project/team was unpredictable, random. But perhaps the hierarchy of managers actually had valuable skills that led to higher success rates of projects achieving that “feeling”? Perhaps they had a knack for picking the right people and for managing people in a way so they worked together more efficiently? Of course they weren't perfect and there were some bad apples, just like any profession.
I wonder what the demise of the hierarchy of managers was caused by? Did the hierarchy of managers lose these skills overtime and become useless? Did programmers just not recognize their value added and throw them under the bus for 30 years until they didn't have a leg to stand on? Was it pure budgetary, cut costs and get rid of the resources with the least perceived value?
DISCLAIMER: I am not a manager. I use to be very hard on managers, then I became one for a while, realized how difficult their jobs can be, and now I am one of the easiest people to manage.
Re: Why don’t software development methodologies work?
#200Earlier quoted context omitted.
The majority of everything in software was discovered by the 70s. Since then we have been reinventing the wheel every 5-10 years on better hardware.
I don't think hardware has anything to do with it. I think the most important factor in this evolutionary cycle is that every 4 - 6 years, new Computer Science/Software Developer STUDENTS enter the market, spend a few years catching up, and then trying to re-invent everything. Rediscovering the territory that they'd not really learned that the industry had already proceeded through at much greater pace than Academia…
No, I mean hardware is genuinely progressing. Software is going in circles. It's a culture thing. Legacy code should mean "battle tested code" not "boring, let's replace it!" We are so busy replacing perfectly working code with the latest fashion that we never advance.