OK, SE is supposedly dead. But the notion that we should just throw up our hands and despair of ever managing programmers, while perhaps attractive to certain workers, is ridiculous. Craftsmen are easily managed.
If coders are craftsmen, then we have ample precedent for how to “make” them. It’s the same as any other building trade. Send them to school for a few months to learn a bit of theory, then apprentice them to a master who teaches them how to do things in the real world. Eventually they become a journeyman capable of working on routine stuff without immediate supervision; after many years, they become masters themselves capable of supervising the work of others. This system has been around for centuries and it works quite well at producing skilled craftsmen.
Lately, even in the building trades the process has become short-circuited. In the interest of cost-cutting, contractors have started using labor that, to put it charitably, is less than properly trained. Sadly, this works because most Americans care more about getting the lowest possible bid than getting quality work. I see the effects all the time in the residential and landscaping fields. I shudder to think what civil structures might be built with such labor. Most software is built with similarly poorly-trained programmers. No wonder most software is so flaky.
Programmers are fundamentally no different than carpenters or other skilled tradesman. The fundamental problem with “software engineering” is that we try to have the carpenters also be the architects and the civil engineers and the plumbers and everything else. This may work for simple projects, just as a skilled carpenter can probably adequately design and build a typical house that involves no unusual features. But putting an ironworker in charge of architecting a skyscraper would be madness. Unfortunately, this is exactly what happens in most software projects.
The central problem with software is not that it involves craftsmanship. Nor does this fact disqualify it from being an engineering discipline Nearly every engineered system involves craftsmanship at some point in its construction. Tin must be bent. The problem is our routine conflation of craft roles with engineering roles.
Finally someone said out loud. I’ve been always wondered why the cs department belongs to the engineering faculties if this shares few things in common with another engineering, and so it does with sciences. Well, thanks jeff
I always considered a large part of SE way out of my picture for reasons as:
1- I feel that most, if not all, concepts after The mythical man month is academic. It is sometimes useful, but not even closely as they want me to believe.
2- The project schedules and budgets I have learnt to deal with does not support even 1/10 of the effort required to write the docs, test the app, review it and such as they tell me I should.
3- I know for sure my competitors don’t use them at all, yet they win over us.
I know (3) for sure because a customer choosen a different studio to go for a SW he needed. After a few weeks he came back here to ask for a technical assessment.
Wonderful.
In retrospect, we should have charged him way more.
As seen before nobody had a benefit from reading blog posts. In most cases it costs the reader time which we all know is money. The only people getting money for this are bloggers and merketing weasels.
I don’t want to participate in the argument over semantics here because it seems trivial and could go on ad infinitum.
However, as a side note from a global perspective, in many countries, you are legally restricted from using the word “engineer” or “architect” in your title unless you have a very specific degree or license.
I had to cringe when someone of the baby-boomer generation recently referred to me as an engineer. It just sounded so … wrong. As a Web applications developer, I consider myself more of an artist or something more poetic. “Engineer” just sounds so stuffy.
Normal engineering has the creative parts, but they also tend to have more non-creative parts. You can automate a factory with robots, but if you are building a bridge out in the field, you pretty much need a bunch of men with welding kits. That’s hard to automate. From a distance that kind of labour can mask the creative side.
In the UK, welders, bricklayers and other skilled technicians are called craftsmen. It’s a different role to an engineer, and does not denote lack of science. There’s a different argument between ‘you need some craftsmen to build it’ - a hell of a lot of software projects are made by welding existing components together - and ‘software engineering is dead’.
The word engineer comes from the Latin ‘ingenium’ meaning ‘Cleverness’. As is the word ‘ingenious’ (marked by originality, resourcefulness, and cleverness in conception or execution - Merriam Webster)
I would argue that software engineer is the most appropriate title for what we do, and it is other types of engineer that are mis-labelled
Sadly I have to agree with “Sales and Marketing”. The big problem with programmers is that we think businesspeople actually CARE about “engineering” or “design principles” or all of that good stuff that we repeatedly say is the “right” way to develop software, when in fact ALL that matters is to get working software that meets the business’ needs out and into the hands of the people who need it.
This is why a hack who writes spaghetti code is infinitely better than the “software engineer” who takes his good sweet time making sure everything is properly decoupled, and implements the right design pattern; the hack’s code is ugly and inefficient, but it works and it’s completed fast.
The sad truth is that software exists as a supplement to existing business functions, and all this talk about “craftsmanship” ignores the real goal.
I agree with the idea that software design is experimental. but this doesn’t imply that you can control it. What it is needed is a different control approach, more similar to the one used in scientific research: propose an hypothesis, define an experiment, test and measure, evaluate results and go back to hypothesis.
Software engineering is not dead, it’s just waiting for the next step.
When the software engineers itself.
Don’t think I’m way out there in the whacked out AI world.
We are approaching sufficient horsepower where self modifying and adaptive code is goiing to become a reality. And not just the little ‘toy’ examples we’ve come up with so far.
I just hope it does not knock on my door and ask me if I am Sahra O’Conner.
I don’t think true arty and crafty people do anything for the sole purpose of function. I think we are far closer to engineers than artists. We have a science and a toolset and a lot of knowhow, and rules/standards to follow, even if they aren’t bound by law. We design and build things to order that have - first and formost -function. Making the function look good is secondary, as it is in engineering. Making it not fall down is our main priority.
Maybe ‘architects’ is a nice middleground as it tends to combine function with form.
First off - I’ve called myself a “master software craftsman” for nearly 20 years now - for much the same reasons alluded to by various posters (and TFA).
Secondly - it never has been and likely never will be engineering in the legal sense of the word - using known, repeatable processes to transform known raw materials (e.g., data) into a result provably knowable in advance. That’s pretty close to the Texas definition, if I recall correctly - which is why it’s /illegal/ for “software engineers” to be called such in TX and several other enlightened jurisdictions.
We’re not engineers. We’re barely craftfolk; we’ve started work on various iterations of the Cathedral at Reims any number of times - and now people think we can bring the Sydney Opera House on spec, on budget, in half the time reasonable.
We’re not engineers, and we likely will be, barring a transformational tragedy roughly analogous to the New London school explosion of 1937 for which software, preferably COTS software, is left visibly holding the bag. We won’t be, barring such an event, because the culture and folklore that have grown up around software development reinforce the traits that actively militate against engineering - namely the lone heroic coder, ‘code complete’, “don’t worry, be crappy” and other such garbage. And it IS going to take an event where a sizable number of people wind up dead; we’ve shown great impassiveness as an industry in the face of large and expensive (but non-fatal to humans) software failures. If I had a penny for every million dollars spent on projects that ultimately were delivered but failed catastrophically, I could retire and put six kids through Harvard Law.
Back about 20-25 years ago, I used to think we were 20-30 years away from a ‘true’ software-engineering discipline. Now, I’d say it’s going to take at least twice that long from now - even if a New London-class failure of software were to happen tomorrow. Some people call it the Microsoft Effect. I think it’s just a byproduct of us as a non-profession, not having any way to overrule technical decisions made by egregiously unqualified people and making them stick.
Prove me wrong. Not with statistically-improbable events 15 or 20 sigma out from the mean - but AT the mean.
This article is great. After 15 years involved in the Enterprise Software Development field I am utterly convinced of the fact that Software Engineering has in its deepest internals noise wrapped by fancy concepts. Also it’s true that many corporations are doing money selling courses, methodologies, certifications, software development based upon “state of the art software engineering techniques”, but I bet for motivated people with talent AND commitment instead. I’d like to meet some day a project manager with these abilities together.