The previous post reached the conclusion that there *is* such a thing as software engineering, and it raised the question: "So what?"
What is the value of this conclusion? Does it matter what we call the process that -- in the end -- produces some software product?
To be frank, no. The argument over what is software engineering, and whether software engineering is really a kind of engineering, is a distraction from the real issue at hand. Hopefully the previous post provides a reasonable resolution to this debate.
The real issue is how to make the process of creating software more reliable and predictable. This "software crisis" (ironically a product of advances in computer capability) encompasses a collection of shortcomings, including (i) a lack of effective techniques for managing software projects, (ii) disconnects between what users need and want and what programmers produce, and (iii) overall poor software quality and performance. The common factor in each of these problems is complexity, and poor management thereof.
The complexity is unavoidable. Therefore the only way out is to find effective ways to deal with it. The key is to decouple these problems to identify solutions for each.
Friday, November 12, 2010
Thursday, November 4, 2010
Software engineering is...
The debate about whether software engineering is really "engineering" has gone on since the term first came into popular use after the 1968 NATO Conference on software engineering.
Since I teach software engineering at Boston University, I'm highly motivated to assert: "Of course software engineering is engineering." Joking aside, it is clear to me that software is "engineered", no matter how it is created.
Perhaps the place to start is to see how Webster's Dictionary defines "engineering" :
1. The practical application of science to commerce or industry.
2. The discipline dealing with the art or science of applying scientific knowledge to practical problems; "he had trouble deciding which branch of engineering to study".
This definition squares well with the commonly-heard expression, "to engineer a product".
More specifically, all engineering fields are characterized by the following features:
a. Formal communication methods -- mechanical engineering uses drawings and engineering change orders, electrical engineering uses schematics, civil engineering uses elevation and detail drawings, etc.
b. Process-oriented -- creating a product ad hoc can be accomplished only when a very small number of like-minded people are involved; otherwise contributing, reviewing and modifying the information comprising an engineering project must follow some defined procedures.
c. Conscious of time, requirements and economic constraints -- in most cases, someone or some organization is investing in a product to address a particular market opportunity, and usually does not have endless patience and cash.
d. Relies on science -- try convincing yourself a bridge will be sufficiently rigid by looking at a sketch on paper; science provides some definite answers through math and logic.
e. Relies on body of knowledge -- when science can't quite provide a definite answer, past experience can.
f. Must sometimes meet standards and code on account of legal liability -- a major consideration in consumer products.
e. Iterative -- much of engineering is creativity, and creativity rarely follows a straight path without errors and insights.
So is software engineered? Let's look at each of these characteristics.
Formal communication methods and process -- Even if programmers engage in ad hoc code-and-fix, one can say that "formal communication" and "process" occurs nonetheless. It just is not particularly apparent to the casual observer since these things largely happen in the programmers' heads. Certainly there is concrete process in almost any software development organization today: source code control, bug reports, requirements documents, agile activities.
Conscious of time, requirements and economic constraints -- A reality of any business, including software. Agile has done a lot to bring prominence to requirements through its user stories.
Relies on science -- Many programmers don't have formal computer science training. Those who do, however, carry with them a store of algorithm and abstract data structure knowledge that influences their judgment, whether they are aware of it or not. Sometimes they explicitly apply this knowledge.
Relies on a body of knowledge -- There's nothing like experience, and programming is no exception. The best code is written by programmers who have written similar things before.
Must sometimes meet standards and code -- Certainly is true of software used in any sort of aviation. Internally, companies define (and increasingly apply) coding standards.
Iterative -- Would anyone disagree? Agile has done a lot of make this characteristic plainly clear.
The bottom line is that all software development is a form of software engineering, done in a wide range of professional quality.
OK, so what? We can argue that software engineering is engineering, but what is the value of this realization? Does this realization lead us to change how software is developed so it is created faster, better, and with more pleasantness all around?
I'll address these questions in the next few posts.
Since I teach software engineering at Boston University, I'm highly motivated to assert: "Of course software engineering is engineering." Joking aside, it is clear to me that software is "engineered", no matter how it is created.
Perhaps the place to start is to see how Webster's Dictionary defines "engineering" :
1. The practical application of science to commerce or industry.
2. The discipline dealing with the art or science of applying scientific knowledge to practical problems; "he had trouble deciding which branch of engineering to study".
This definition squares well with the commonly-heard expression, "to engineer a product".
More specifically, all engineering fields are characterized by the following features:
a. Formal communication methods -- mechanical engineering uses drawings and engineering change orders, electrical engineering uses schematics, civil engineering uses elevation and detail drawings, etc.
b. Process-oriented -- creating a product ad hoc can be accomplished only when a very small number of like-minded people are involved; otherwise contributing, reviewing and modifying the information comprising an engineering project must follow some defined procedures.
c. Conscious of time, requirements and economic constraints -- in most cases, someone or some organization is investing in a product to address a particular market opportunity, and usually does not have endless patience and cash.
d. Relies on science -- try convincing yourself a bridge will be sufficiently rigid by looking at a sketch on paper; science provides some definite answers through math and logic.
e. Relies on body of knowledge -- when science can't quite provide a definite answer, past experience can.
f. Must sometimes meet standards and code on account of legal liability -- a major consideration in consumer products.
e. Iterative -- much of engineering is creativity, and creativity rarely follows a straight path without errors and insights.
So is software engineered? Let's look at each of these characteristics.
Formal communication methods and process -- Even if programmers engage in ad hoc code-and-fix, one can say that "formal communication" and "process" occurs nonetheless. It just is not particularly apparent to the casual observer since these things largely happen in the programmers' heads. Certainly there is concrete process in almost any software development organization today: source code control, bug reports, requirements documents, agile activities.
Conscious of time, requirements and economic constraints -- A reality of any business, including software. Agile has done a lot to bring prominence to requirements through its user stories.
Relies on science -- Many programmers don't have formal computer science training. Those who do, however, carry with them a store of algorithm and abstract data structure knowledge that influences their judgment, whether they are aware of it or not. Sometimes they explicitly apply this knowledge.
Relies on a body of knowledge -- There's nothing like experience, and programming is no exception. The best code is written by programmers who have written similar things before.
Must sometimes meet standards and code -- Certainly is true of software used in any sort of aviation. Internally, companies define (and increasingly apply) coding standards.
Iterative -- Would anyone disagree? Agile has done a lot of make this characteristic plainly clear.
The bottom line is that all software development is a form of software engineering, done in a wide range of professional quality.
OK, so what? We can argue that software engineering is engineering, but what is the value of this realization? Does this realization lead us to change how software is developed so it is created faster, better, and with more pleasantness all around?
I'll address these questions in the next few posts.
A good start
Two recent articles (MITnews), (blogs.msdn.com), both entitled "Teaching real-world programming", report how MIT computer science students improve their code-writing skills through novel code reviews. Specifically, MIT professors Saman Amarasinghe and Charles Leiserson require students taking 6.172 — Performance Engineering of Software Systems to submit their project code for face-to-face reviews by experienced Boston area software developers.
Some comments:
(1) Having taught software engineering for some time, it is clear that a lack of basic code-writing skills hampers students' ability to succeed in computer science and software engineering. The 6.172 effort is a very good step forward.
A one-time code review certainly is helpful. To take things to a level where lifelong code-writing habits are formed may require students to carry out projects as "apprentices" to experienced software developers. In such apprenticeships, for a certain period of time, students would be responsible only for converting psuedo-code to code, allowing them to focus on developing code-writing skills without the distractions of design and algorithm development.
(2) Both the MITnews and blogs.msdn.com articles discuss the usefulness of comments. Comments in code are great if they are well-written, and certainly more helpful if they address the purpose of the code, as Barry Perlman states in a comment about the MITnews piece. It seems human nature, however, (or at least for humans who become programmers) to feel that the purpose for which code was written is obvious and does not need to be explained. Accordingly, most programmers write only about the solution represented by the code, and leave implicit some very useful information -- namely, the issue that calls for the solution.
Additionally, words by themselves are a cumbersome medium, in particular for explaining the purpose and the workings of code. Figures and videos are often necessary for effective and efficient communication. In programming languages with which I'm familiar, however, it is not possible to include figures and videos in comments.
Lastly, a comment may need to refer to two or more sections of code, raising the question, "In which section should the comment about these sections be placed?"
A commenting method termed "Issue/Solution/Link" (ISL) addresses these shortcomings by allowing comments to be composed in a format such as html, and linked with code. The ISL technique contains a mandatory "issue" section, where the issue/purpose of the code, and not the solution, is explained and described. Often, the issue can be expressed with a single question, such as, "How does the system render so smoothly?"
Although an issue may address conspicuous software features such as impossibly-fast rendering, many issues are mundane, such as: "How does the system undo a delete operation?"
The solution section of an ISL comment provides an explanation of the solution chosen to resolve the issue, largely to spare programmers the time and effort to infer the intentions underlying the code. The best-written solutions unambiguously reveal the techniques employed, and allow programmers to quickly become fluent with the related code.
Both the issue and solution sections may contain figures, videos and other non-textual data that support and clarify the written comments.
Links emanating from the issue/solution sections provide a bi-direction connection with the corresponding sections of code.
The process of developing the habit of programming with ISL comments requires a bit of discipline and effort. With time and practice, the process becomes easier and more natural.
The benefit of using ISL is quite substantial. Estimates vary. However, Peter Hallam, Microsoft's tech lead for C#, estimated once that the fraction of time a programmer spends studying code is on the order of 75%. ISL vastly reduces this 75%.
(3) Barry Perlman's comment at the end of the MITnews article is right on target -- the big payoff is the thought process required to write [good comments].
Some comments:
(1) Having taught software engineering for some time, it is clear that a lack of basic code-writing skills hampers students' ability to succeed in computer science and software engineering. The 6.172 effort is a very good step forward.
A one-time code review certainly is helpful. To take things to a level where lifelong code-writing habits are formed may require students to carry out projects as "apprentices" to experienced software developers. In such apprenticeships, for a certain period of time, students would be responsible only for converting psuedo-code to code, allowing them to focus on developing code-writing skills without the distractions of design and algorithm development.
(2) Both the MITnews and blogs.msdn.com articles discuss the usefulness of comments. Comments in code are great if they are well-written, and certainly more helpful if they address the purpose of the code, as Barry Perlman states in a comment about the MITnews piece. It seems human nature, however, (or at least for humans who become programmers) to feel that the purpose for which code was written is obvious and does not need to be explained. Accordingly, most programmers write only about the solution represented by the code, and leave implicit some very useful information -- namely, the issue that calls for the solution.
Additionally, words by themselves are a cumbersome medium, in particular for explaining the purpose and the workings of code. Figures and videos are often necessary for effective and efficient communication. In programming languages with which I'm familiar, however, it is not possible to include figures and videos in comments.
Lastly, a comment may need to refer to two or more sections of code, raising the question, "In which section should the comment about these sections be placed?"
A commenting method termed "Issue/Solution/Link" (ISL) addresses these shortcomings by allowing comments to be composed in a format such as html, and linked with code. The ISL technique contains a mandatory "issue" section, where the issue/purpose of the code, and not the solution, is explained and described. Often, the issue can be expressed with a single question, such as, "How does the system render so smoothly?"
Although an issue may address conspicuous software features such as impossibly-fast rendering, many issues are mundane, such as: "How does the system undo a delete operation?"
The solution section of an ISL comment provides an explanation of the solution chosen to resolve the issue, largely to spare programmers the time and effort to infer the intentions underlying the code. The best-written solutions unambiguously reveal the techniques employed, and allow programmers to quickly become fluent with the related code.
Both the issue and solution sections may contain figures, videos and other non-textual data that support and clarify the written comments.
Links emanating from the issue/solution sections provide a bi-direction connection with the corresponding sections of code.
The process of developing the habit of programming with ISL comments requires a bit of discipline and effort. With time and practice, the process becomes easier and more natural.
The benefit of using ISL is quite substantial. Estimates vary. However, Peter Hallam, Microsoft's tech lead for C#, estimated once that the fraction of time a programmer spends studying code is on the order of 75%. ISL vastly reduces this 75%.
(3) Barry Perlman's comment at the end of the MITnews article is right on target -- the big payoff is the thought process required to write [good comments].
Subscribe to:
Posts (Atom)
