Discipline Envy
Discipline EnvyWe want SoftwareEngineering to be like math; instead it is turning out to better resemble the "soft disciplines" of psychology, journalism, etc.
Interestingly, in the Dewey Decimal System of classification, Computing appears in section 001 (a subcategory of 000 - General Works). It does not appear in either section 500 (Pure Sciences) or 600 (Technology (Applied Sciences)). So, according to the original classifiers, Computing is not a science! Source: http://lib.sdstate.edu/lib02/dewey.html
{Bear in mind that not everyone wants software engineering to be like math! Some of us are very pleased to see the cold equations being checked and driven back, at least in one area...}
[I think the original poster means that SoftwareEngineering should be rigorous like electrical engineering, rather than fluffy and amorphous. That doesn't mean SoftwareEngineering needs to be mathematical, just that it should be logical and informed by reason, not whim.]
{That makes sense.}
An argument based on analogy is like a house built on sand.
The programming discipline has suffered a long term identity crisis. It never seems happy to be itself but instead pretends to be the discipline it serves at the moment, or the discipline from which it has drawn the most members. First our discipline wanted to be like mathematics. Oh how nice it is to reason with artifacts of pure thought. Then we were a science, off on a voyage of discovery with the scientific method at our side. Now we've matured to engineers, liberated by certified processes and writing our handbook.
I don't believe it. When I stoop to analogy I pick journalism. Hey, like us, the journalism grunts are idolized and reviled at the same time and all work under deadlines. And we will be a lot better off when we let our young whips design the systems and make our old sages do editorial maintenance. Unlike journalism, we promote the wrong direction.
But that's analogy. Instead we should study our own. Instead of throwing anchors out to established practice, let's find the fastest among us and hitch on to them. That's what I want from our investment in patterns. I move fast and I want to move faster. -- WardCunningham
The problem with 'hitching' a ride with the 'fastest' amongst us is that the vast majority cannot be absolutely sure 'we' are moving in the right direction. The direction becomes a matter of rhetoric and faith instead of a matter of evidence and proof. At some point that direction is questioned, as evidenced by the recurring software crisis and resulting paradigm shifts. We need to follow the most effective among us, the ones that can balance the three typical project driving forces: speed, cost, correctness. -- MartinSpamer
The problem with complaining about analogies is that they're all we have to live with, for now. How else to explain our discipline, to non-members, other than by analogy? (See MetaphorsWeLiveBy.)
The roles people play within a development team very much depend on their choice of analogy. I think of programming like story-telling. Or maybe like acting. The point is that, above and beyond questions of efficiency and performance, good design requires that we be able to empathize with our objects. Otherwise we will no be able to communicate the design to other people. That would bye-bye to good implementations, bye-bye to extensibility, bye-bye to object reuse, bye-bye to all those virtues that are vague and fuzzy but nonetheless real.
I design things and then I walk around asking questions like ...
On the other hand, I work with people who see programming as engineering. They tend to ask different sorts of questions.
Thanks, William. I swallowed what I was about to say. Now I'll try to restate it. Analogies are not all we have. We have objective events and distinct personal sensations. While I am programming, I do not think, "I am being a journalist / engineer / scientist." I am simply putting something together. We could, as Ward suggests, start building up a vocabulary for those events and sensations. Every part of a vocabulary comes from somewhere else, but the putting together of it can become the way of talking about software without using analogy. Use direct description, in other words, instead of circumlocutions and analogies.
That having been said, it is clear that I borrow a persona when talking about design to another person, or to myself out loud. And the persona I choose matters. Exactly as you described about the would-be scientist, or would-be engineer, or would-be behaviorist. So I regularly confuse my new-to-OO colleagues by asking how it feels to be this object with those responsibilities, and such like questions. They live inside a different sort of dialogue about their design. They want it 3rd-person, impartial, objective, measurable. I like it subjective, comfortable, and measured in a very few ways.
That was nice, your bringing in the persona issue, because that does come from analogy, even if talking about the profession is done with direct vocabulary. For each analogy about the profession, it is good to see what you can learn and borrow, and then go back to direct vocabulary. -- AlistairCockburn
I use analogy to ask "What can I steal?" Programming isn't architecture, but some tricks that work for architects may also work for programmers. I agree that the danger of metaphor is the insistence on a one-to-one mapping. The danger of no metaphor is that you wind up reinventing the wheel -- or never realizing that a wheel would help.
What do other professions have that we don't? See EngineeringEnvy. --BetsyHanesPerry
When trying to work out confusing elements of a design, I fall back on storytelling almost immediately. "Programming" sounds like writing solid code to some people, so perhaps storytelling doesn't work there, but I certainly believe in AnalysisAsStorytelling. --BrianSchuth
We do not rely just on analogies - we still have actual examples. An actual example can be as simple as seeing a screenshot or code example, and comparing it's ease of use to some other tool. If the two tools both have advantages, then we've successfully proven that both are useful and a viable option. If one is proven to get the job faster for certain things, and the other is proven to get the job done faster in other areas, then someone can pick and choose which tool suits the job. The receiver of information does not always need analogies, but real world examples of why, and how. If we've just talked about other things in life using analogies, it's not as likely to get across to the receiver as using a real world situation where A used B to get C done.
We need to see more examples of why SomethingA is so better than SomethingB. If there aren't any examples, then maybe the analogies will not get through. I've tried analogies, but I always end up using real examples if I really want to get a point across. I'd like a code example, screenshot, and a description, rather than I would purely a description or opinion. We'd rather see some code being put to use than I would hear about all the good things it could or it might do in relation to an orange or pizza.
Maybe:
Didn't we programmers just start out as apprentices, helping our "masters" as Junior Programmers, until we rose up through the ranks? Don't we work in guilds?
To me, seems more like the process of training doctors than reporters. Only, our patients evolve a lot more quickly.
Analogies are what human brains construct in order to keep developing an understanding of the Universe.P lease visualize the evolution of programming as a contributive process where more and more elements take place. First, it was all within the sphere of expert mathematicians. Progressively, the affairs of programming involve as well other disciplines, such as the social sciences (anthropology, psichology, law & politics), arts (music, graphic design, animation), economy (e-commerce), even fashion (the cool factor). In the beginning the programmer was rowing alone on a small boat. Now, cyberspace is becoming a huge cruise, where so many other skills are also involved.
Daniel Henry Thomas
Perhaps we need to get back on track here and return to the discussion of discipline. As an engineer I view the development of software as simply another step towards solving a system. Systems require solutions that are composed of many more components than just the software. Those of us who are JustaProgrammer may not see it that way, but when one looks at the Big Picture® one sees that this is really the case.
Therefore, we need to analyze our development of software as a component of "the" solution, and not as the entirety of it. Even if I work on a DLL to provide services to a much larger application I still need to consider my work in relation to the rest of the system. Yeah, my contract says that I will deliver such-and-such functionality with so-and-so interfaces, but my discipline as an engineer requires that my (intermediate) solution fits into the overall system.
Likewise, if I am charged with solving a system that requires electronic, mechanical, or other components then I need to analyze and design my components and the separation of duties appropriately. If I can't figure this stuff out by myself then I must call upon other professionals who can provide the expertise to do so.
So, what makes our software engineering discipline any different than, say, mechanical engineering? Or electronics? Or pneumatics, or hydraulics, or anything else? Just because we are dealing with esoterica doesn't mean that the discipline of software engineering should be any different from that involving the mundane. Professionalism is professionalism.
What is missing is one of two things:
See: NewAnalogiesForSoftware, InkBlotSoftwareEngineering, SoftwareGivesUsGodLikePowers, SoftwareEngineeringCriticism, EvidenceEras, GreatLispWar
EditText of this page
(last edited December 23, 2014)
or FindPage with title or text search