Quote:

Original post by MaliciousDigit Then I realize it and this site makes sense now. Most of these guys ARE contractors.

Sorry, I'm not a contractor. And I've never been one, either. (Thinking you can obtain a reasonable idea of my professional experience from my GDNet journal, which I have deleted more than once, is questionable, btw. Just ask me; it's easier.)

Quote:

Original post by Muse Quote: Original post by Oluseyi The only reason that this bifurcation and economies of scale don't reliably apply in software design is not because software is special, but because software development is a young and relatively primitive discipline. I disagree. There is an important distinction between software engineering and other engineering disciplines: in software engineering, the difference between the design and the product is not very profound. If you're a civil engineer, there is an enormous difference between your blueprint and the bridge you're building. You need an immense amount of labor to translate the blueprint into the bridge--and there's essentially no way to translate the bridge back into a blueprint. For a Software Engineer, your product is source code, and you can easily convert your UML diagram into the skeleton of a solution, and your solution back into a pretty good blueprint via source documentation tools.

Hmm.

Civil Engineer : blueprint
Software Engineer : UML diagram

Blueprint → building : immense amount of labor
UML diagram → software artifact : immense amount of labor

Building → blueprint : surveying, costly, inaccurate
Software artifact → UML diagram : analysis, decompilation, costly, inaccurate

Source code is an intermediate product, not an end result, so comparing source code to buildings is wrong. Correcting that analytical error, it becomes clear that the parallels between software development and other engineering disciplines are very strong. So I'm going to have to stand by my original statement: software development is a young and primitive discipline.

Quote:

The only way to design a solution so thoroughly that any low-value programmer could accomplish it is to specify it explicitly in psuedo-code--but there is not much value in doing this, because generating real source code is nearly as easy.

UML is a pseudo code form, except that it fails to capture a number of implementation concerns. And source code generated from UML - I believe you called it a skeleton - is often barely an improvement over pseudo code.

Quote:

Original post by Oluseyi Source code is an intermediate product, not an end result, so comparing source code to buildings is wrong. Correcting that analytical error, it becomes clear that the parallels between software development and other engineering disciplines are very strong. So I'm going to have to stand by my original statement: software development is a young and primitive discipline.

I continue to disagree. Source code is the final product of the software engineer. There is no need to extend this discussion to the trivial final step of converting that source code into machine instructions; that is not a human job, and we are discussing humans here.

Quote:

Original post by Oluseyi Blueprint -> building : immense amount of labor UML diagram -> software artifact : immense amount of labor

You've juxtaposed the work necessary to transmute a blueprint into a bridge to that necessary to transmute a UML diagram into a complete software project, implying that they're the same sort of thing. But are they? In the software project, what does that "immense amount of labor" consist of? If you spend 8 hours programming, what did you spend all your time doing? Were you banging out code as fast as you could type? Or were you thinking "Hmm, should I use a list or a hash for this temporary storage I need?" or "Well, I need to make this latent call at this point, should I block on it, or loop over it until it's done?" Those are all fine-grained design decisions.

It's not that it doesn't make sense for a software project to have a few high-level Software Engineers in charge of the overall design (in direct analogy to civil engineering, where a few engineers are in charge of establishing the blueprint for a large project). It's that, even after the SEs have finished their design, an enormous number of low-level design decisions remain to be made by the programmers responsible for the implementation.

Another way of reiterating my argument: If you wrote a software project design sufficiently precisely (to use your own term), that no more design decisions needed to be made, then the blueprint you wrote would be the software. This is why I can't stomach the argument that programmers are fungible: for them to do useful work they need a certain creativity and a certain perspicacity, which needless to say differentiates them.

Frob: you said that you worked with an excellent coder, but also that coders are essentially interchangeable. Doesn't that seem like a contradiction to you?

This is the most rediculus topic I've read in years. Did anybody even think of out-sourcing a game project, they must be i****s. Cost of games are not that important due to the high payoff, out sourcing the project will only kill you in paper works.

Quote:

Original post by Oluseyi Don't blame me because you have an arbitrarily abstract notion of what constitutes a "design." The fact remains that if you provide sufficiently precise instructions, a team of interns can write Halo 4 (or whatever passes for a superlative example for you).

I disagree. If the McFood example teaches us anything it's that if you give precise instructions to a bunch of monkeys you get mediocre product. I don't think anyone here would call McDonald's food the pinnacle of culinary excellence. Similarly, if you give very precise instructions to to a bunch of interns, you'll get a mediocre piece of software. It'll work as specified, but there'll be nothing special about it. It certainly won't be a top game.

So in the same way that if you want a really good meal, you go to a restaurant with a really good chef, if you want a really good game, you better have really good developers.

There's also significant evidence that small teams are a lot better than large (go read The Mythical Man Month if you're in doubt). Small teams mean each member has to do more which means you need a team made of the best people, not a huge farm of monkeys.

Also, I think Muse makes a valid point - software is a lot more complex than making a burger or building a house. The complexity of even a modest piece of software dwarfs most anything else humans can construct. As complexity increases, so does the precision needed to specify the task. To the extent that a detailed enough description of the problem is the final product.

Quote:

Original post by Muse Quote: Original post by Oluseyi Source code is an intermediate product, not an end result, so comparing source code to buildings is wrong. Correcting that analytical error, it becomes clear that the parallels between software development and other engineering disciplines are very strong. So I'm going to have to stand by my original statement: software development is a young and primitive discipline. I continue to disagree. Source code is the final product of the software engineer. There is no need to extend this discussion to the trivial final step of converting that source code into machine instructions; that is not a human job, and we are discussing humans here.

I don't think so. Code is a means to and end; ultimately, the goal is an application which can be used by your customers. They don't care what your code looks like, and in most cases you're not selling code, you're selling the final application built from that code.

Quote:

Original post by Driv3MeFar <...snip...> I don't think so. Code is a means to and end; ultimately, the goal is an application which can be used by your customers. They don't care what your code looks like, and in most cases you're not selling code, you're selling the final application built from that code.

I don't mean to say that source code is the typical deliverable that gets shipped to customers. What I mean is that compiling source code is a machine-task. It is not interesting to talk about it as part of the responsibility of a software engineer, or a programmer for that matter. Literally anyone could walk up to a fully configured, complete and correct software project and hit "Compile"--it's a null task for us humans.

I think what the AP who started this thread wanted to point out is that a good developer is both good at design and coding. If you define a "coder" as a worker that takes very precise instructions and converts them into source code, well then there are very few uses for those kind of workers. When in a project, there are typically a great deal number of open issues on how various parts work and how they work together... unless your main design already has all the details in it (at that point the design document is infact really the source code), then those that need to implement the design still have problems to solve...

as for that story about that uber coder that missed the point of some "high level fancy crap", how many do you really know that are that extreme? what I do get sick of are the developers that go off on OO madness "everything is objects, blah, blah, blah" 9 times out of 10 their designs suck because they don't realize the design issues and what needs to be done to make the project do something, so when people read their design docs, they say, hmm... does not actually say anything... just a lot of crap.. but we know what to call the project file now...

but nevertheless, if management does not give the oppurtunity for the workers to do something interesting where they can grow, then the workers end up feeling like burger flippers and they do not get to improve... if a company treats you that way, the time is to leave and find new work as that place will now give back to you.

Quote:

Original post by Driv3MeFar Quote: Original post by Muse Quote: Original post by Oluseyi Source code is an intermediate product, not an end result, so comparing source code to buildings is wrong. Correcting that analytical error, it becomes clear that the parallels between software development and other engineering disciplines are very strong. So I'm going to have to stand by my original statement: software development is a young and primitive discipline. I continue to disagree. Source code is the final product of the software engineer. There is no need to extend this discussion to the trivial final step of converting that source code into machine instructions; that is not a human job, and we are discussing humans here. I don't think so. Code is a means to and end; ultimately, the goal is an application which can be used by your customers. They don't care what your code looks like, and in most cases you're not selling code, you're selling the final application built from that code.

Not only that, but the quality of source code is not directly proportional to the quality of the resulting software artifact. Thousands of software developers write ugly, hard to read/maintain code that yields efficient, pleasurable use to customers. Plus, a software developer's job is not done until the source code produced has been proven to translate into object/machine code and software artifacts/behaviors in desired fashion. If the result of a "mere translation step" is the arbiter of the quality/completion of your work, then that result is your product.

Quote:

Original post by Muse Quote: Original post by Oluseyi Blueprint -> building : immense amount of labor UML diagram -> software artifact : immense amount of labor You've juxtaposed the work necessary to transmute a blueprint into a bridge to that necessary to transmute a UML diagram into a complete software project, implying that they're the same sort of thing. But are they?

You've arbitrarily selected the large task of converting a blueprint into a bridge, as opposed to the proportionally smaller yet semantically and conceptually identical task of, say, converting a blueprint into a table for mass production at IKEA. I see right through that, so, to answer your question, yes, they're the same sort of thing.

Quote:

Another way of reiterating my argument: If you wrote a software project design sufficiently precisely (to use your own term), that no more design decisions needed to be made, then the blueprint you wrote would be the software. This is why I can't stomach the argument that programmers are fungible: for them to do useful work they need a certain creativity and a certain perspicacity, which needless to say differentiates them.

The blueprint would be the software prior to a translation step requiring no creative input. If the form of that blueprint is machine comprehensible, then, yes, it's the software - compile away. But it typically isn't, which is why we need "coders".

For the record, I never said programmers were fungible. I said coders were. (Go back and re-read my post.)

Quote:

Original post by Jerax Quote: Original post by Oluseyi Don't blame me because you have an arbitrarily abstract notion of what constitutes a "design." The fact remains that if you provide sufficiently precise instructions, a team of interns can write Halo 4 (or whatever passes for a superlative example for you). I disagree. If the McFood example teaches us anything it's that if you give precise instructions to a bunch of monkeys you get mediocre product.

This "insight" is predicated on the assumption that the only variable in final quality is the quality of the instructions, not the quality of the ingredients or any intermediate steps such as flash freezing and reconstitution.

Given your lack (and, honestly, it's not your fault; I'd be asking the impossible) of control for these other variable factors, I have to view your disagreement as irrelevant to the analysis of the consistent procedural outcomes under investigation.

Quote:

There's also significant evidence that small teams are a lot better than large (go read The Mythical Man Month if you're in doubt). Small teams mean each member has to do more which means you need a team made of the best people, not a huge farm of monkeys.

That's just bad reasoning. First of all, nothing states that you need many monkeys. If you have one or two designers who can provide sufficiently precise instructions in an efficient manner, you may only need as many monkeys - or even fewer - to follow the instructions and yield the output artifact. Frankly, we're in the realm of pure speculation here.

Quote:

Also, I think Muse makes a valid point - software is a lot more complex than making a burger or building a house.

I call total and utter bullshit.

Simple software is no more complex than a simple burger, and probably less complex than a simple house. Monumentally sophisticated software is probably still not as complex as a skyscraper (consider every aspect of a full functional skyscraper - HVAC, security, communications, electricity, structural integrity, service access, etc, etc, etc). In other words, your contention is merely software developer ego - particularly common with game developers, who like to tell themselves that games are the most complex type of software. Who cares, really?

Again, you've only substantiated my contention that software development is a young and primitive discipline: other disciplines have learned to specify rigidly abided interfaces that enable specialization and knowledge/component reuse. Have you ever thought about the complexity of a house down to the level of the screws and mounting brackets inside your wall switch? Architects don't specify to that level; at some point they hand responsibility over to electricians and plumbers and HVAC engineers, etc. Software, primitive discipline that it is, too often requires that the entire infrastructure be essentially "hand fabricated" - including, in some instances, the tools for component fabrication.

Take a critical look at what you actually do.

Oluseyi, you make a fantastic argument, seriously.

I believe that your statement 'given sufficiently precise instructions to any coder, the product of their efforts will be what was desired' is a valid one.

I don't think I'd be wrong if I said that the point of contention is the definition of 'sufficiently precise instructions.' I believe that in this context, it is an infinite limit such that, approaching it virtually becomes the desired result itself and the coder becomes a point of minutia that can be considered to not exist.

This point of minutia is basically a first year comp-sci student: sure, they understand the syntax and they can 'code', but they're not going to work for any substantial project any time soon and, in the context of a commercial product, can be considered to not exist.




[sorry of I offended any comp-sci students - if you are one then the mere act of reading this post brings you beyond the skills you have learned in class]

Quote:

Original post by SnOrfys I don't think I'd be wrong if I said that the point of contention is the definition of 'sufficiently precise instructions.' I believe that in this context, it is an infinite limit such that, approaching it virtually becomes the desired result itself and the coder becomes a point of minutia that can be considered to not exist.

Yeah, but if the instructions are so precise then an experienced programmer put them together anyway. Someone somewhere did some programming in order to get to this point, that person wasn't painting by numbers and they were sufficiently skilled to specify enough of a program to pass it to someone else (i.e. they weren't replaceable).

The 'sufficiently precise instructions' argument is common sense and it applies to almost any discipline. But it is too much of a generalization to be applied usefully.