Engineering takes time. And the market doesn’t wait.
It’s sad, but true.
These statements that Software Engineering is dead are the products of academic jargon. They must say something really extraordinary to keep their attention on. They could really say something obsessive, like if they had Tourette’s syndrom or something like that.
Programming is typing variables in your code file and doing some if-statements - and it’s all the same if you do it agile,fetish or some other peculiar affection.
OMG! Ridiculous nonsense!!
So all you self-appointed software “craftsman” don’t apply scientific method in your testing and analysis? Well… let the aeronautics, telecoms, nuclear, military and scientific industries be duly warned.
Engineering and craftmanship are NOT mutual exclusive, many of the statements here are utterly naive, kowtowing, or trying to justify a CS degree instead of an engineering degree, or only “code” websites.
Please have a look in the dictionary:
Craftman(ship): A man who practices a craft with great skill
Engineering:
a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
b. The profession of or the work performed by an engineer.
You EARN the title of craftsman; if you are crap you are not a craftsman, nor an engineer for that matter.
Peony: Spot on.
Timmay!: “Software has never been engineering” WTF???
Stuart.
I’ve looked over the documents and the comments and I’m coming to the conclusion that this blog is becoming more about the “debatefullness” of the topic rather than relevant information that may be useful or change how we work on a daily basis.
For instance, I hate paired programming, while others at my place of work love it. So discussions about personality based development processes would be of interest. We program mainly in Microsoft technologies, so discussions about the pros and cons of specific technologies would be of interest.
But debating whether we are engineers, craftsmen or somewhere in-between makes NO DIFFERENCE to my day/work/life. Call me a janitor for all I care - as long as I keep doing what I’m doing.
Can we please steer the blog back onto topics that do something OTHER than raise meaningless debates on emotive topics?
Software is intangible in nature whereas the end products of other engineering disciplines are tangible.
You may apply the most rigorous process to build high quality software but there will always be some bug hidden away in your code that simply can’t be caught when reviewing your code. E.g., the bug may not manifest itself until the software is run on a specific target platform.
Testing frameworks and test cases themselves are pieces of software and may have bugs of their own that may give you false positives or negatives.
It is therefore very difficult to identify hard and fast metrics to measure software engineering activities. I totally agree with Tom DeMarco’s statement:
“…its [Software Engineering’s] metrics are accordingly much less precise in capturing the things they set out to describe. They must be taken with a grain of salt, rather than trusted without reservation.”
Use metrics but don’t follow them blindly.
As long as software engineering is locked on paper, it is dead. If it can be an active collaboration tool, then it will live. Many projects have died because of the lack of design and the ability to maintain the software after it’s creation.
No one wants to update paper based files, active updating, similar to the Microsoft Team Foundation Server, which can actively update Project files, track bugs, test code check-ins against architectural requirements and function within the operational infrastructure, is key to success in software.
Software bureaucracy is dead, as to software engineering? Not certain.
Woohoo!
Right now, I’m 21, and have been programming since I was 13 or 14. I’ll be finishing a BS in CS within a year, and I’ve been saying for almost that entire time - maybe since I was 16 and knew better how to program things - that programming of any sort belongs under “Art”, not “Science” or “Engineering”, because it is primarily a creative process.
Science - We don’t propose theories, and we don’t do experiments. The theoretical side of computer science is a combination of mathematical proofs and artistic inspiration.
Engineering - As has been complained about for so long, there are no standards in the ways that real engineering has. Bridges and buildings must be up to certain codes, for example.
Art - Taking an abstract idea or definition, and making it a reality, be it writing a book, writing a piece of music, drawing a picture, or writing a program.
I am By training a mechanical engineer (One semester to go and I graduate!!!) and by employment and hobby a programmer. I think that the opinion being forwarded is BUNK. Software engineering is not dead and in fact is one of the most needed direction of advancement in programming.
For one thing, saying that programing can’t be engineering because it’s creative is like saying something can’t be a car because it has more than 2 seats. I think that argument indicates a misunderstanding about what engineering is. Yes some engineering projects (and some software ones) are not hardly creative, but most interesting engineering projects involve quite a lot of creativity. The engineering bit has more to do with the design process used to make sure it does what it’s supposed to, than it does with how you come up with the basic ideas of how it will do it.
Additionally, I think a lot of what Jeff is saying may come from looking at HOW software engineering is being done and the piles of buricrapic process that gets tacked on. That’s not the parts of engineering that will make programs better (but rather what is needed to be 100% sure the engineering got done right).
What is needed is the idea that we should have detailed and accurate specs to design to, that we should measure, analyze and test programs and that we should actually understand how the systems we’re working with work. I rather suspect that most programmers would love to do that last one if they had the tools to do the measurement, and analysis (when was the last time you could say with total confidence “This fix works and didn’t break anything”?).
This view of software engineering is incomplete.
If you are talking about gaming industry, yes, software is pure craftsmanship - although the frameworks and tools for game development have evolved to a point where they have become, well, software engineering tools
If you are talking about business software, your view is not correct. Applications that have a lot on the line (=support entire businesses) tend to use proven and tested components (think SAP, think trading engines, think SharePoint…)
If you are talking about online applications, like forums and such, then again a big “yes” to experimentation.
Twitter just proved that it is a piece of junk from a software engineering and security perspective (frequent “timeouts” softened by that ridiculous picture of a whale) and now a serious security hole.
Facebook is plagued by similar problems. It kills the browser every now and then (especially IE), it times out occassionally but overall it works because if it goes down, it isn’t that critical, it will be back up tomorrow.
Then there is google. If it goes down, we got Bing, we got Yahoo.
If a business-line application goes down, the entire business stops (or gets very sluggish with a lot of pi$$ed off customers). Different game entirely.
Tom DeMarco used to be a big name, lately he has been throwing platitudes around (similar to those of Richard Florida and his creative class platitudes). In the meantime, world got flat, then it got spiky again, IT was irrelevant now it is the killer again…
Does it matter?
Does it work? If it works, it matters.
The thesis might be right (can’t argue really), but what you fail to mention is that as any craft vs. manufacturing competition crafts, while have survived as a niche service (we still have farmers’ markets), are all but extinct. Unless you have concrete evidence that most of the people buy from farmers and not from supermarkets, I would still believe that software engineering is almost extinct, giving way to mass-manufacturing process.
The whole discussion of computer science, programming, software development, and “software engineering,” versus “engineering” is just so boring and cliche at this point. We are arguing about semantic jibber jabber.
Those of you who insist that programming is just art like painting or whatever are just smoking too much pot to be completely honest.
It’s more interesting to talk about how to better develop software than all this same arguments over and over again blah blah blah.
I swear, I could recite every side of these arguments in my sleep.
“Wah wah wah, ‘real engineers’ can actually kill people with mistakes. Wah wah wah, ‘real engineers’ have legal requirements that programmers don’t.”
Honestly, who cares? Does it make any of you feel like less of an intellectual because you aren’t an electrical engineer that couldn’t write a maintainable C program to save your life?
Computer Science is fundamentally different from pure mathematics, empirical science, electrical engineering, mechanical engineering, etc.
Get. Over. It.
This is a field where you use your brain and perhaps a fairly cheap set of devices. Teenage hackers are somewhat common mostly because it is very accessible and involves a lot of logic that is amenable to a certain type of person. You don’t need to have access to the sort of equipment or safety training that traditional engineers have. This doesn’t make it any less challenging or “impressive,” if you like, to master it.
Honestly, it’s just kind of embarrasing to see programmers struggle with this question. And again, it’s just so cliche at this point.
I have to agree with Stuart and Dave Markle. What is DeMarco’s definition of a software engineer or even Jeff’s?
I went to school for computer engineering, mostly focused on software. If you compared our comp sci dept to the comp engr dept one is more theory while the other (comp engr) was more application of computer science to real world problems (which matches what I understand engineering to be). It’s a method of thinking and applying what you know to a problem.
Those processes (guidelines), and ways to manage, seems to be what has people assuming is the only engineering aspect of software engineering which I have to disagree with. Processes and methods to manage, in all engineering disciplines, will change with time.
Most disciplines have a creative aspect to them. Programming itself is a creative act. In civil engineering creating a highway could be considered a creative act. Sure there are metrics, but what is considered set in stone today will likely change 5+ years from now. Just look at older text books.
What scares me about this blog post is that it’s sending the message to budding computer scientists and software developers that they don’t need to pay attention to software engineering practices. In the absense of any software engineering practices, what is the next best alternative? Glorified hacking with venerated gurus working in dark rooms churning out beautiful code when they’re ready to grace the world with their creations? http://www.codesqueeze.com/why-office-gurus-are-bad-and-the-buses-who-hit-them/
I think it might be more accurate to say that “CMMI Level 5 project management is inappropriate for developing blogging platforms” instead of the general statement, “software engineering is dead.” Several other comments have addressed this, that rigorous software engineering is appropriate for different kinds of projects like compiler development, so I won’t belabor that point.
A true software engineer has a toolbelt of best practices, techniques, and approaches that can be applied to different types of software projects. Are you working on aileron control software for Boeing? Then you’ll apply the heaviest practices possible, with complete software specifications and signoffs possible to CYA. Are you working for a startup with a vague idea, little cash, and no ROI model? Then you’ll apply a lighter weight process with an iterative lifecycle, rapid prototyping, with a concentration on vetting your ideas and getting to market as quickly as possible to grab market share. Working for an open source project with no revenue model? Then hack away!
Finally, are you somewhere in the middle, working for a medium size project for a dotcom, with a dozen developers, PMs, testers, designers, and business stakeholders with an estimated year over year revenue of 1 million dollars? Then you’ll want: the accountability of a medium weight software specification; usability testing to validate initial business ideas; software estimation to determine milestones and deadlines for business commitments; software processes to have repeatable release practices; iterative development to verify that your estimates are correct; and automated regression testing and unit tests to reduce bugs in your delivered software.
Software engineering means different things to different developers. Many of the detractors of “software engineering” view it as unnecessary documentation in the way of getting to the fun part of coding. But you have to remember that software engineering is more than just generating paperwork. It’s about knowing what SDLCs are available to the practitioner, such as RUP, Iterative, Scrum, or Waterfall. It’s about knowing that estimation and setting milestones is a good thing when you have commitments that you need to adhere to (it’s easier to steer a ship around an island if you know its location well in advance). Using project management software is appropriate if you need to make sure you’re still on track for hitting your milestones. Requirements analysis and change control is good if you have a client who keeps trying to add features to the product that threaten to compromise your milestones (death by a thousand papercuts). It’s about knowing that commenting your code and documenting your interfaces and APIs is a good thing if someone else needs to know how to maintain your system when you’re gone (see ‘hit by a bus’ above). It’s about having repeatable successes by documenting the processes used to get the product to production. It’s about using unit testing to prevent new bugs from cropping up when you make changes to your system, and verifying that old bugs stay fixed.
I don’t believe that software engineering is dead; otherwise we would all give up on unit testing, setting milestones and deadlines, and writing comments in our code. Knowing that Coding Horror is an advocate of unit testing, I know this is not the case.
Part of engineering is about knowing your goals and constraints, the tools at your disposal, and how to navigate tradeoff space to achieve your goals. We all operate within a constraint space to do what we do best. I absolutely know that I can’t let 4 developers do whatever they want for 4 months to deliver a million dollar ROI project, so I apply software engineering to achieve the business goals within this constraint space. I apply the right dose (this is where craft comes in) of software engineering practices to ensure that I can achieve the business goal, keep my career, and successfully deliver the product on time.
In this regard, software development as an engineering discipline is still very much alive and strong.
I’ve always said that Software Engineering is, like any art form, creative. Yes, there are logical, precise and defined aspects to it that form a solid base, but once that foundation is laid then the rest, for me at least, is very much an evolutionary process. I tend to spend a good deal of time formulating in my head how a project is going to be coded, how the pieces will fit together and operate, and then I begin coding, at which point much of it just seems to ‘flow’, like paint onto a canvas.
One could easily compare software engineering to music. Music has a very defined scientific foundation, the frequencies/wavelengths of sounds, the precise increments for scales and harmonies, the timing of each measure. But, you take those very exact principles and you give them to, say, Mozart, and what do you get? Something wonderful! Something created from seemingly nothing.
The foundation of software engineering is what lets us compose our symphonies of code.
Curiously enough, I bookmarked this article from 2005 a couple of days ago…
“Computer Science” is Not Science and “Software Engineering” is Not Engineering - http://www.geocities.com/tablizer/science.htm
I guess you could say we solve problems, but are we using mathematical principles to determine if a solution will work in the same respect that engineering needs to assure that materials have the appropriate tensile strength when building axles?
For business applications, many times we are just validating premises. TDD helps us validate that we have created an answer to an abstract story. But what engineering practice conducts QA with “Should-defy-laws-of-gravity” as a test case? Physics constrains what an engineer can do, while we are constrained in some cases by mathetimatics, but in many cases we listen to abstractions, answer with different abstractions, and argue about logic.
It really annoys me that people insist on black-and-white definition that the process of programming a computer to do something useful to humans is “engineering”.
One might insist that the process for turning a tree into something useful to humans is “engineering”. This immediately puts chopping firewood, making a coffee table and building a covered bridge in exactly the same category. Fail.
The same metaphor applies appropriately to ANY application of skill. It’s the intent that dictates the precision required and the risks assumed.
Excellent post from Phillip, and it’s how I feel – I think half the time lately with Jeff being lost on me, I never even check the article from my news reader. It’s not like I can block Jeff out. I could use a filter, sure, but I just do what I do with other authors, because once in a while, like the 2005-2006 days, Jeff might write an article on par enough to warrant my time.
This is not new
Even the long forgotten book “the Man-Month Myth” explains why software development isnt engineering.
I’ve written about it some time ago:
http://design-to-last.com/Technical/software-development-is-it-engineering.html
Daniel
what we do is craftsmanship, not engineering.
Maybe you do, I do both; although perhaps I do engineering, and software development, and not software engineering? In embedded systems there is a lot of engineering. Whether ‘software engineering’ exists, or is worthy of recognition as a distinct discilpline may be up for debate, but I am an engineer, and I build software. Perhaps software is just a tool in my engineering toolbag.
Software development in the realms of web development, corporate management systems, and banking are probably not ‘engineering’, and probably never where. I’ve always believed that, but maybe that is because I am a ‘real’ engineer, I resent the abuse of the term, or am just a snob.
In my work I need to know about FIR filters, fast Fourier transforms, control theory, decibels, Shannon theorem, the Nyquist limit, and plenty of other stuff that ‘real’ engineers need to know. I doubt any of that ever enters the domain of a lot of software development.
However plenty of good software, and a lot of dross too remains ‘crafted’, and I have no argument against that. Most software develpers like the cache of the ‘engineer’ moniker perhaps, but most also resented the constraints ane ‘methodologies’ that were then imposed on projects to try and turn them into ‘engineering’. They lack the necessary discipline, and just don’t get it, and because the good ones are also smart, they can see that much of it is nonsense; and that’s not how to get good work out of people.
I once challanges Stephen Mellor in a panel session at a conference. He was advocating Model Driven Architecture