## Software Development Welcome to Hell. The purpose of this course is to scale your software development skills and attitudes from Fundamentals I, II, and OOD to a reasonably large scale of systems building. You will also learn some specific skills, which will probably be irrelevant in a few short years. ### What is the cost of software? [Fiat Chrysler Recalls 5.3 Million Vehicles .. Software Glitch]](http://felleisen.org/matthias/Articles/bugs-vehicle-recall.pdf) [Apple’s New So!ware Aim: Fewer Features, But Fewer Bugs](http://felleisen.org/matthias/Articles/apple-bugs.pdf) Most software is prototype quality and gets thrown away. Just ask any developer. If software evolves from a prototype to a full-fledged product, however, it may exist way beyond your life span. Some of the code that serves you right now -- especially in banks -- was written in the 1960s in a language called COBOL (whose inventor should be punished not lauded with a conference). Many of the people who produced this code are dead. This code is wrapped in layers of Pascal, C, C++, Java, Ruby (on Rails), JavaScript, and PHP. On occasion, people who write these outer layers need to dive all the way down to the original code and adjust it. So the software pipeline looks like this: ``` -- prototype --+-- bury | +-- harden -- develop -- test -- deploy -- maintain -- ``` And we know this, which is why we teach a rather different core programming curriculum than most schools (and companies acknowledge this). ### How does the Core Curriculum and Sw Dev address this cost problem Here is our starting point: - If your software survives the prototype stage, - it will survive you. From this we easily get, - treat your software well and it will treat you and your successors well. That is, - you and your successors will have a huge advantage - if you construct this software systematically. It will cost you and your successors fewer hours, less hassle. It will cost your team and your company less money. But, we all know that seeing a concept just once and in only one context does not really convey it well. So we have a curriculum where you see the idea of - creating software systematically in five different contexts, not counting your first co-op where you may see the opposite. Where this course fits in. It is the last course on your development as a programmer. It is _not_ a software engineering course. ``` * <--- sw dev | " " first co-op " | * <--- ood / \ / \ logic ---> * * <--- fundamentals II \ / \ / * <--- fundamentals I ``` For details, you may wish to read the design rationale at [Developing Developers](http://felleisen.org/matthias/Thoughts/Developing_Developers.html) [[ **Note** This link goes to an off-campus site. You might encounter opinions contrary to yours. ]] ### Attitude Your attitude to code: - code as if the future maintainer of your code is a psychopath who ... - this future maintainer might be you, and you don't want to hate yourself - code calls for permanent good care .. because you never know where it ends up Another aspect of code is that it is creative artifact and we are creators. Arguably, the invention of software has turned millions of people into "paid creative artists". An artist _creates_ artifacts; we create software systems. A typical artist also associates his "ego" with his "products" -- and that's bad for software. Indeed it is bad for art, too, and artist learn to cope in painful "crits". We will do so, too. #### Egoless Programming You must disassociate your ego from your code and yet use your ego to become a great developer. **Reading** The hand-out is a chapter from Weinberger's _Psychology of Programming_ and it is the only required reading in this course. ### Development Skills (wrt Software) You will _not_ learn to use the latest and greatest languages, IDEs, tools, frameworks, web foobars, and app barfoos. Tech schools teach this stuff---but a year later, it's worthless Here are some of the goals. We would like you to develop - a basic idea of what "plan top-down, build bottom-up" means - an eye for specifying interfaces and protocols - ... and their limits - a sense of the value of good tests and test harnesses - ... and their limits - some insight into systems integration, - the planning that goes into it and - the failures that must be planned for ### Personal Skills (wrt Software) 1. I---as the manager of this company---see incredible value in _pair programmin_ at a large scale. So everyone must work in pairs. By contrast, I do _not_ believe in _team programming_ for such small systems as the one we will produce (no more than 20 Kloc in Java). 2. I also believe in permanent critique. - as a scientist I count those people as my friends who constantly try to poke a hole into my theories. (The others are just pretenders.) So this course will therefore resemble a course in the fine arts with permanent crits. Like artists, you will present your code and others will critique it. You will watch such crits and mentally apply the dialogues to your own code base on days when you're not involved. So here is what you can learn: - from pair programming - communicating properly with a partner (see 'log book') - working with someone whose skills differ from yours - working with someone whose personality differs from yours - coping with an irresponsible partner (see 'log book') - from presenting your artifacts - presenting code - accepting flaws and errors in your own code that others point out - reacting to such discoveries - from serving on a review panel - reading code on the fly for a problem you know - discovering problems: - gaps in the design - failure to match specs - bugs - stylistic problems - how to improve your use of your chosen language ### What is a software system? For our purposes, a piece of software is dubbed a _system_ if it has components that - deal with a _start-up_ phase, - maintain a _steady state_ phase, - shut it down gracefully, and - comes with a facility (config files, config DSL) to configure it to different circumstances. A system consists of several software components, with clearly delineated responsibilities with interfaces and protocols that describe their interactions. A system may also consist of _distributed_ components. In this course we will construct such a system in a systematic manner from a monolithic system. A system may allow extensions at run time. Operating systems, web browsers, web servers, and many other well-known pieces of software are such systems. Our system will allow dynamic extensions for configuration purposes and perhaps passive ones while it runs. A system may consist of systems, but a semester is too short to construct meaningful examples of this kind. ### How do you develop a software system? A long long time ago, one of the stone-age software engineering researchers was asked to describe a software construction process. He put up a strawman that generalized the above idea of how software comes about into a so-called _waterfall_ model. (His name is Barry Boehm.) Modern software developers babble "agile" and "sprints" and "tdd" and other such words. Some of the suggested readings will make you buzzword compliant in this regard. What I know is this: - someone needs to know where you want to end up - this someone must identify essential components - and must know how to arrange the construction of these pieces so that you can demo asap What this means is that someone creates an overview picture, figures out (crude) dependencies, and identifies runnable milestones. This is called _top-down planning_ because you start from the big picture and go down to details. Then it's time to make a plan to build these pieces like a solid house: - foundation first - load-carrying walls - .. all the way to the roof. That's called _bottom-up_ coding. Next time we will take a close look at this idea. ### Language Wars