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.
Fiat Chrysler Recalls 5.3 Million Vehicles .. Software Glitch
Apple’s New So!ware Aim: Fewer Features, But Fewer Bugs
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).
Here is our starting point:
From this we easily get,
That is,
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
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
[[ Note This link goes to an off-campus site. You might encounter opinions contrary to yours. ]]
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.
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.
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
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).
I also believe in permanent critique.
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:
For our purposes, a piece of software is dubbed a system if it has components that
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.
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:
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:
That’s called bottom-up coding.
Next time we will take a close look at this idea.