|
139 | 139 | "The waterfall approach to software engineering comes from the engineering tradition applied to building physical objects,\n",
|
140 | 140 | "where Architects and Engineers design buildings, and builders build them according to the design.\n",
|
141 | 141 | "\n",
|
142 |
| - "Software is intrinsically different:\n" |
143 |
| - ] |
144 |
| - }, |
145 |
| - { |
146 |
| - "cell_type": "markdown", |
147 |
| - "metadata": {}, |
148 |
| - "source": [ |
149 |
| - "### Software is not made of bricks" |
| 142 | + "Software is intrinsically different: **software is not made of bricks.**\n" |
150 | 143 | ]
|
151 | 144 | },
|
152 | 145 | {
|
|
158 | 151 | "Software systems differ in material respects from physical systems.\n",
|
159 | 152 | "Much of this has been rehearsed by Fred Brooks in his classic\n",
|
160 | 153 | "['No Silver Bullet'](http://ieeexplore.ieee.org/xpl/login.jsp?reload=true&tp=&arnumber=1663532&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1663532) paper.\n",
|
161 |
| - "First, complexity and scale are different in the case of software systems: relatively functionally simple software systems comprise more independent parts, placed\n", |
| 154 | + ">\n", |
| 155 | + ">First, complexity and scale are different in the case of software systems: relatively functionally simple software systems comprise more independent parts, placed\n", |
162 | 156 | "in relation to each other, than do physical systems of equivalent functional value.\n",
|
163 |
| - "Second, and clearly linked to this, we do not have well developed components and composition mechanisms from which to build\n", |
| 157 | + ">\n", |
| 158 | + ">Second, and clearly linked to this, we do not have well developed components and composition mechanisms from which to build\n", |
164 | 159 | "software systems (though clearly we are working hard on providing these) nor do we have a straightforward mathematical account that\n",
|
165 |
| - "permits us to reason about the effects of composition.\n" |
166 |
| - ] |
167 |
| - }, |
168 |
| - { |
169 |
| - "cell_type": "markdown", |
170 |
| - "metadata": {}, |
171 |
| - "source": [ |
172 |
| - "### Software is not made of bricks" |
173 |
| - ] |
174 |
| - }, |
175 |
| - { |
176 |
| - "cell_type": "markdown", |
177 |
| - "metadata": {}, |
178 |
| - "source": [ |
179 |
| - "\n", |
| 160 | + "permits us to reason about the effects of composition.\n", |
| 161 | + ">\n", |
| 162 | + ">\n", |
180 | 163 | "> Third, software systems operate in a domain determined principally by arbitrary rules about information and symbolic communication whilst the\n",
|
181 | 164 | "operation of physical systems is governed by the laws of physics.\n",
|
182 | 165 | "Finally, software is readily changeable and thus is changed, it is used in settings where our uncertainty leads us to anticipate the need to change.\n",
|
183 | 166 | "\n",
|
184 |
| - "-- Prof. [Anthony Finkelstein](http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/), UCL Dean of Engineering, and Professor of Software Systems Engineering\n" |
| 167 | + "-- Prof. [Anthony Finkelstein](http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/), UCL Dean of Engineering, and Professor of Software Systems Engineering" |
185 | 168 | ]
|
186 | 169 | },
|
187 | 170 | {
|
|
231 | 214 | "> limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other\n",
|
232 | 215 | "> Agile Methodologies as \"hackers\" are ignorant of both the methodologies and the original definition of the term hacker\n",
|
233 | 216 | "\n",
|
234 |
| - "-- Jim Highsmith.\n" |
| 217 | + "-- Jim Highsmith\n" |
235 | 218 | ]
|
236 | 219 | },
|
237 | 220 | {
|
|
366 | 349 | "metadata": {},
|
367 | 350 | "source": [
|
368 | 351 | "\n",
|
369 |
| - "* Don't ignore design\n", |
370 |
| - "* See if there's a known design pattern that will help\n", |
371 |
| - "* Do try to think about how your code will work before you start typing\n", |
372 |
| - "* Do use design tools like UML to think about your design without coding straight away\n", |
373 |
| - "* Do try to write down some user stories\n", |
| 352 | + "* Don't ignore design.\n", |
| 353 | + "* See if there's a known design pattern that will help.\n", |
| 354 | + "* Do try to think about how your code will work before you start typing.\n", |
| 355 | + "* Do use design tools like UML to think about your design without coding straight away.\n", |
| 356 | + "* Do try to write down some user stories.\n", |
374 | 357 | "* Do maintain design documents.\n",
|
375 | 358 | "\n",
|
376 | 359 | "BUT\n",
|
377 | 360 | "\n",
|
378 |
| - "* Do change your design as you work, updating the documents if you have them\n", |
379 |
| - "* Don't go dark -- never do more than a couple of weeks programming without showing what you've done to colleagues\n", |
| 361 | + "* Do change your design as you work, updating the documents if you have them.\n", |
| 362 | + "* Don't go dark -- never do more than a couple of weeks programming without showing what you've done to colleagues.\n", |
380 | 363 | "* Don't get isolated from the reasons for your code's existence, stay involved in the research, don't be a Code Monkey.\n",
|
381 | 364 | "* Do keep a list of all the things your code needs, estimate and prioritise tasks carefully.\n",
|
382 | 365 | "\n"
|
|
0 commit comments