4 ms·
Yeah, software engineering is a craft, and generally the only way to learn those fast is to learn from others.
by fsloth 8y ago
Yeah, software engineering is a craft, and generally the only way to learn those fast is to learn from others.
- blub 8y agoIt's not a craft, in its purest form it's an engineering discipline with specific rules, procedures and standards. The crucial point is that most of us a doing programming, and not software engineering. Learning from others is hit or miss. One can certainly learn to program from others, but that's not enough to be able to do software engineering.
- sanderjd 8y agoConvince me that its "purest form" is an engineering discipline rather than a craft. What distinguishes it from things that you would agree are crafts? Or are all crafts actually engineering disciplines in their purest form? I think this is a pretty interesting question. Personally, when I was young, I would have said what you said: it's engineering, specifications go in and properly engineered finished product come out. I was proud that my CS program was contained in an engineering school and that all my friends were in other engineering disciplines. The longer I do this though, the more I think it's a craft: fuzzy idea is put to a skilled practitioner and through discussion and creativity, one or more artifacts are created to satisfy that idea. You could argue this is true of more traditional engineering disciplines as well, and I would probably agree. I'm not totally sure what the distinction between the two things is. So tell me what the distinction is and convince me what we do is more the one than the other. For what it's worth though, apprenticeship is also a very important part of engineering education. At some point, you have to see people do the thing, regardless of whether it's engineering or a craft.
- blub 8y agoWhen we say software development is a craft, we're saying that it's like shoemaking, pottery or woodworking. Can the immense complexity of today and tomorrow's software be tamed by applying the same principles of building a cupboard? No, it requires an engineering mindset. We're now limping along as an industry and it's not obvious because SW is bringing in massive amounts of money and we can basically get away with a lack of quality.
- fsloth 8y ago"When we say software development is a craft, we're saying that it's like shoemaking, pottery or woodworking." The point being, there are intricate details that are very hard to deliver in the traditional class-room oriented school environment with well defined requirements. Those do not state anything about scalability. Crafts can scale - like for example how the old giant cathedrals and castles were built in middle-age europe. They don't say anything about mindsets either. You need an engineers mindset to buid a cathedral or a castle. The specific problem with crafts is that adapting to new requirements is a complete hit and miss process. The reason for this problem is the lack or proper theoretical framework in which to pose ones work and into which embed the requirements themselves. The program verification people are working towards solving this problem, see for example Leslie Lamport's work in TLA+. But until we have a general, mathematical proof backed compiler for requirements, as well as for the program implementation, we are pretty much stuck with craftsmen. (Well, we have proof compilers but those are at the moment completely unusable for general programming since they are so complex to use.)
- fsloth 8y ago"It's not a craft, in its purest form it's an engineering discipline with specific rules, procedures and standards." Sorry, but I have to strongly disagree. In it's purest form the core of software engineering - i.e. programming is a craft. The other parts are mostly about creating processes so that craftsmen can create something together without stumbling into eachother. The difference between a craft and engineering are numerous. - engineers generally need a license - engineering is about repeatability and creating dependable cost estimates - engineers are required to study for years for a very good reason. You can be a rockstar programmer out of highschool. Just having a bunch of cargo cult gibberish bound into a book does not make a craft into an engineering discipline. It's harmfull to call programming engineering. Engineers have curriculums that can teach them pretty well what is expected of them once employed. Not for programmers - or, well, software engineers. If there was even one curriculum that could churn out good programmers dependably, don't you think this model wouldn't be copied instantly elsewhere? If such a curruculum existed, do you think think software interviews would be filled with whiteboarding just to check out that the candidates understand even the basics? I think this incapability to create a curriculum for actually creating good programmers is the best evidence that programming is a craft. It's such a complex topic that you can't create a mass curriculum that would serve all equally. Not with our current understanding, anyway. Maybe if we could teach everyone assembly, and Haskell , and have them implement compilers and languages as a standard things would be different. The second best way to learn programming without being born a programmer savant is to learn from others while doing. Apprenticeship is the traditional way to train craftsmen. Programming is so much more like a craft than engineering that it's best to call it a craft. Craft is not a deragatory term. It just means we don't understand it theoretically well enough to teach it properly.
- sanderjd 8y agoI tend to come down on your side of the craft vs. engineering debate, but then I disagree with basically your entire argument for it :) You list three distinguishing features of an engineering discipline. The first and third swap cause and effect; a field doesn't become engineering because once it requires licensure and years of study. Surely you wouldn't agree that a successful campaign to require those things for software developers would bestow the status of engineering upon the work. Your second point seems closer to the truth, but I'm not so sure it's true. If someone comes to a civil engineering firm and says, "design us a road between this city and that city", that is often a unique challenge because the terrain between those two cities is likely unique, maybe it requires a big bridge or a tunnel, which will be akin to but not identical to other bridges and tunnels you've built before.