►Software Development
▼Lectures
•Lecture 1:   Software Development
8.3.0.10
    contents  ← prev  up  next → 

Lecture 1: Software Development

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?

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. 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 software creation and life cycle look like this:

  -- prototype --+ -- bury

                 |

                 | --- bury

                 |

                 | ------ bury

                 |

                 | ------------ bury

                 |

                 |

                 +-- harden -- develop -- test -- deploy -- maintain --maintain --maintain --maintain --

The creation process itself really starts when someone decides the softwrae is a “keeper” because people have to read the code over and over again: to prevent usage problems, to fit into deployment contexts, to add features — rinse and repeat.

And we know this, which is why we teach a rather different core programming curriculum than most schools (and companies acknowledge this).

The Core Curriculum and Software Development

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,

– if you construct this software systematically,
– you and your successors will have a huge advantage

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 four (formerly 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

Each course simultaneously aims to train two different sets of principles:

  • social/psychological relationship to software

  • technical/coding relationship to software

Once in industry, you will supplement these ideas with concrete skills for specific software tool chains. These tool chains change to rapidly that it makes no sense for university-level courses to teach many of those.

The Psychology and Sociology of Code

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.

Egoless Programming

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.

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 programming 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 embrace 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.)

Every person can learn to thrive on negative feedback though most are (no longer) able to do so naturally.

How We Teach, What You Can Learn

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

    • what it takes to present code so that others understand quickly

    • accepting flaws and errors in your own code that others point out

    • reacting to such discoveries in a positive manner

  • 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

Language Wars and First Partner Choice

Administrtivia

    contents  ← prev  up  next →