Use cases and software requirements
The key to writing good use cases is to be complete. Use cases are an accepted idea now, but a lot of them are written on the backs of napkins. In an agile project we might code from one use case, but still, the more completely that use case is described, the more surefooted the coding will be.
I think I was the first person to teach use cases in the United States:
OK, I’m not a graphic designer. But this website does show what I care about in interface design – that users can find what they want, without getting confused or clicking the wrong button. When I make this view of the program a priority, I get a better design and better code overall.
Object oriented design
Design is the bridge between requirements and coding. A designer should produce specifications for code objects that will be straightforward to code and maintain. Most of the objects will represent things in the world, or things in computer world (like buttons and textboxes). But the key classes in a good design don’t really represent anything – they encapsulate sources of change.
Object oriented design doesn’t automatically lead to maintainability, reuse, and the other promised benefits. Object oriented languages give us tools that can be used to make a robust program, if we want to use them. I discussed these ideas in a paper published in the Journal of Object Oriented Programming in 1994:
I have more than thirty years experience speaking in front of groups. I’ve taught a variety of technical subjects, done comedy and storytelling on stage, acted in award winning dramatic productions, and spoken before crowds at political rallies. My strengths are rigorous thinking, clear and simple language, humor, and attention to the audience.
Documentation is an afterthought in most software development, and it’s really hard. Even when we try, it is very difficult to describe something as dynamic as a program. Because I’ve done so much teaching, I’ve come to think of program code as a graphical object – people have to look at it, and in designing it we can ask what they see and understand.
Using graphic design principles developed by the statistician Edward Tufte, it’s possible to get a dramatic improvement in the expressive power of documentation.
Deep knowledge – C, C++, C#
I’ve programmed and taught the C family of languages for more than 30 years. Here’s some of my advertising from the early 90’s.
I have built programs using all of these languages, so I can program in them, but somebody who does it all the time would be faster than I am.
R and statistical analysis – Recently I’ve been working in R, writing a package which uses R and C++ to do smooth regression. Learn more about smooth regression.
SQL, data modeling – I’m good at SQL and data modeling, don’t know much about database admin issues like capacity planning, security, and so on.
Adobe web tools – Fireworks, Dreamweaver, Flash, some Premier.