Software engineering is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

My instructor, when explaining this definition has told me that the terms "systematic", "disciplined" and "quantifiable" imply "one after another, structured", "repeatable", and "measurable" among various other possible interpretations. However, it's the second part of the definition that confuses me. When talking about what "operation" implies, he described it this way: "it's the process of maintaining the software, like updating or patching pieces of it. Earlier we used to remove the whole software and change the source, recompile it and install it back. This part of definition is more or less of historical significance - the way engineering was thought of in other disciplines like Mechanical Engineering."


I am really confused about what the definition implies about SE.

  • If "operation" was just the process of maintaining the software, why include it in the definition independently?
  • If not, What do the terms "Operation" and "Maintenance" imply in the definition?
  • Don't maintenance and Operation and everything come under development? Let's say we are developing an automatic updater component of a software for maintenance, doesn't that mean we are "developing" the "maintenance" part too? Why include the other two in definition then?

Please explain me what SE really means. Thank You!

  • 2
    Not to disagree with your esteemed professor, but "operation" is most certainly not "maintenance." Commented Jan 15, 2013 at 17:45
  • @RobertHarvey: Well, he actually said that it was more about the "process of maintenance" rather than "maintenance" Commented Jan 16, 2013 at 9:21
  • 3
    "Earlier we used to remove the whole software and change the source, recompile it and install it back." - We still do exactly this even today Your professor's definition of operation is clearly wrong, since maintenance is already listed, it would actually be more "operating" the software your maintaning and developing.
    – Ramhound
    Commented Jan 16, 2013 at 15:45
  • 1
    @ForbiddenOverseer - I do that daily when I maintain software that is being updated because a defect was reported against it.
    – Ramhound
    Commented Jan 17, 2013 at 11:53
  • 1
    @ForbiddenOverseer Any update will remove the software as soon as a newer version is successfully installed.
    – gnasher729
    Commented Jun 16, 2018 at 22:35

3 Answers 3


"Operation" has to do with deploying, configuring, starting/stopping, and monitoring the software. For example, at my shop, development builds a tarball of the application and stages it to a specific location on the production server. Another group takes the tarball, expands it into the target directory, sets up Kerberos credentials, adds entries to several databases, etc. We have several utilities that monitor the applications; one gathers statistics, one issues an alert if an application has gone down, one bounces the app if a connection's been dropped or we need to get a new Kerberos ticket, one archives and rotates log files, one looks for and identifies core files, etc. There's also a configuration file that can be updated if an IP address or port number changes, or if some application-specific configuration parameter needs to be enabled/disabled, etc.

None of these things involve touching the source code, so it's a separate activity from maintenance and development. All of these activities have well-defined processes and procedures1 associated with them.

Software Engineering isn't about writing code. Software Engineering is about developing processes and procedures that make the act of writing and running code more reliable and repeatable.


Maintenance (at least in my head) encompasses all the non-coding activities involved with managing an application over its lifetime. This includes (but is not limited to) managing defect and incident reports, deciding which defects are fixed in the next patch, scheduling and staging patches, etc. Some other examples from my shop are migrating applications from one server to another, migrating a customer from one backend application to another, doing performance and traffic analysis and spawning additional instances to handle increased traffic or minimize response times, etc.

Development (again, in my head, "official" definitions may vary) is anything that touches code, whether it's writing new code from scratch or patching existing code.

1 - Process == what you do, procedure == how you do it.

  • That was nice! What exactly is maintenance in this regard? and What does maintenance have to do with development of software? (I mean does it include developing or not?) Commented Jan 16, 2013 at 9:19
  • @ForbiddenOverseer: see my edit.
    – John Bode
    Commented Jan 16, 2013 at 12:02
  • Let me summarize what I understood: SE is more than just writing code, "operation" is about maintenance activities that have nothing to do with the code of software whereas "maintenance" is about maintenance activities that may have something to do with the code inside our software. The boundaries between these three terms are not that clear, meaning some of the activities we perform may come under more than one of them. Was I right in my understanding? BTW, "Maintenance encompasses all the non-coding activities involved with managing an ..." is confusing because of that "all non-coding". Commented Jan 16, 2013 at 14:56
  • Again, these are definitions I use, not necessarily what you'd find in a SE textbook. "All non-coding tasks" simply mean anything that doesn't involve modifying the source code. Assigning defects to developers is a maintenance task, but not a coding task, it that makes things more clear. Migrating a customer from one server to another is also a maintenance task, but not a coding task.
    – John Bode
    Commented Jan 16, 2013 at 15:14
  • I think I got what ur saying there... Thank you!! :D Commented Jan 17, 2013 at 6:22

Software engineering and the definitions are as pliable and ambiguous as you want or need them to be.

While people end up throwing away a design and just fixing things that is more a function of deadlines and realistic deliverable schedules.

There is no such thing as the mythical man month, and there isn't any hard and fast canon on what software engineering is.

I've coded since the 1980's, but only a few times with a design at the outset. That's why Cline is offering the non-explanation. It's cynicism we all get under.

Now, I find the comments that software isn't as disciplined as mechanical beam design or electrical circuit design rather gobsmacking. They don't seem to realize just how much is deterministic inside firmware, hardware, and software in all the ways like every science in they are repeatable, observable, predictable, deterministic, falsifiable, ontological, and so on.

True, when you build a steel I-beam and you specify the flange dimensions and the tensile strength there's not too much else to know about designing around them.

Rather, it is true that there is FAR MORE to be deterministic and knowledgeable about inside the software process - You could demand a transistor by transistor or functional explanation of circuitry and firmware registers for every processor, controller, and SOC chip. We don't because we don't take the time nor demand that kind of granularity. But that doesn't mean we couldn't.

Bill Gates was famous for knowing the Intel 8086 instruction and register sets for software but in no way was he a software engineer. He got his degrees by donating $100M+ to university wings. That's when I threw away my IEEE membership, there's no point in following a professional standards body that rolls over to whore itself for money showing what it really values.

I would argue that like all definitions of broad and perhaps countless the things that might be classifiable inside it that you think of software engineering not just as a definition but also a tension.

Tensions are good for quantifying somewhere between concepts.

Is there software engineering in software operation? Yes.

Is there software maintenance inside software engineering. If one planned a project with post commission maintenance, then yes.

Do all things that qualify as software operation qualify as software engineering? No.

Do all things that qualify as software maintenance qualify as software engineering? No.


SE is mostly BS, because software is not a physical artifact.

Real engineering disciplines (electrical, civil, mechanical, chemical) are applied science. They accumulate knowledge about the limitations of materials and use that to build systems that are safe and effective. We estimate the time and cost of physical construction projects after the design is complete. For novel projects estimation is still inaccurate.

Software development is ALL design, and every project is new. (Otherwise we would just reuse existing code). The limitations are not physical but psychological, and they are highly variable. There is no standard "programmer-hour". Some programmers can solve problems in hours that others will never solve. There is little or no difference between the work needed to produce an estimate and the work needed to produce a solution.

We have learned some techniques for organizing code that seem to help. However poor programmers not only don't follow those techniques, they don't understand them. In this way "software engineering" resembles "education science" -- there's no magic formula for programming or teaching.

  • I disagree that your view applies in every situation. I think software is such a deep and broad field today, that some software can and should be engineered, while some need not be. Commented Jun 17, 2018 at 16:12
  • 1
    Also it sounds like you’re trying to repeat an argument from an older blog post that’s been circulating for years. I’ll see if I can dig up a link. But I think that post’s argument was more nuanced. Commented Jun 17, 2018 at 16:57
  • 1
    Two come to mind, elegantcode.com/2011/06/22/… and cs.usfca.edu/~parrt/doc/software-not-engineering.html Commented Jun 17, 2018 at 17:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.