Gerhard'd Software Development Papers

These papers are over 10 years old. I am posting them here because the free personal web space I have been using on Verizon for all these years is going away 20 September 2014. So I am now republishing with Google instead of Verizon.

---

RAD Rapids Methodology - Amplifies my original RAD Rapids paper to incorporates my learning over the last few years. Paper is styled after Kent Beck's Extreme Programming Explained. The methodology is way more traditional, but still seeks to be light and agile.
Software Development Methodologies - Extremely brief overview of the major software development standards and my personal list of methodology books.
Documentation - Describes the documentation I like to see created for a project and discusses applicable standards.
User Interface Design Essentials - I was real proud of a big red arrow I created and a page switch device that became a work flow manager, so I wrote a paper to show them off! (They are both in proprietary internal software, so I can't mention names.)
Data Modeling Concepts - Handout for the initial data modeling meeting to explaining what the basic terms mean. For example, logical data model, Entity Relationship Diagram, Data Element Dictionary.
Database Design Essentials - After reading a lot of books, I decided I should explain my own methodologies. Idea was to use in training the junior staff.
SQL Server Essentials - A learning tool I created when I was trying to transition from SQL Server 4.2 to 6.5.
Original RAD Rapids Methodology - Useful for shops which have a lot of small projects which can be handled by individual programmers. Representative of the chaotic nature of the way the RAD process typically seems to work. This particular paper was written in 1996.
Code Grading Scheme - Grades code from A to F. Incorporates both quick and through review methodologies into a single grading scheme.
Java Checklist , JSP Checklist - Designed to facilitate peer reviews by suggesting what should be reviewed.

---

How to Automate your Law Practice aka Document Assembly Getting Started in Document Assembly

Document Assembly is the automated production of documents. Ask the user a few questions and spit out a document like a Will, Trust, or Contract.

Document Assembly is how I became a programmer. While I was a lawyer, I developed techniques to automate my law practice. They may seem pretty obvious to software engineers, but this was pretty advanced for a lawyer in the late 1980s. Actually, I've been told is pretty advanced for lawyers in this century too!

I enjoyed the automating my law practice so much it became a serious hobby. At some point, I decided it may be more fun to see if I could get paid to do this hobby full time. I hooked up with Retrieval Systems which was making a document assembly system for a legal publisher, made the switch in 1988, and haven't looked back since!

Pleasing Developers

Just read an article by Alex Handy on the cover of the June 1, 2010 SD Times "For APIs, pleasing developers is key to successful evolution". Sounds like, well, duh, but the article still has some good whys. Some takeaways: a) APIs are important and have to be maintained, b) developers want straight forward calls (REST), c) developers want stable APIs so their apps don't break, d) developer favor working code examples over documentation. Nothing radical there.

But it got me to thinking. There is a separation of concerns here. The folks producing web APIs typically have data that they are experts on. They want people to use their data, but the data experts can't be experts on all possible user communities. That's where the API comes in to separate the concerns. The data owner provides an data centric API and the developers who know individual user communities make the data useful to that community. No wonder it's such a powerful model.

Good article on the importance of people over process.
Characterizing people as non-linear, first-order components in software development

Naval Analogies

“Software Development” is like navigating upriver with a 20 year old chart – you have a general idea where you are going, but never know when you will run around on an uncharted shoal.

“Mere matter of implementation” is like the rocky jetties at the harbor entrance – they can still sink the boat, but most crews should be able to easily avoid them. Brought up when the real topic of discussion is whether you’ve actually found a safe harbor.

Code as Design

A colleague of mine referred me to the notion of Emergent Design as discussed by Neal Ford. Part of Emergent Design is Code = Design. This reminded my of the elegant essays by Jack W. Reeves.

In both cases the argument is the same: code is the final manifestation of the design process. You don't "build code" to a design - the code is the design. You then take your design through a build process (compilation) to get an actual useful product (executable code). So you don't complete the design process until your code has been completed. It really explains a lot about software development and is a core belief of mine.

Debunking Cyclomatic Complexity

Great article by Andrew Binstock. Basically they did a survey that showed for the majority of modern code, the McCabe Cyclomatic Complexity Number does not tell you anything useful about the probability of defects. Basically, the number has to be greater than 25 to predict defects but must code is below 25 and from 1-25 the survey found no correlation between the number and the defect count.

Component Testing

The January 2009 issue of Software Test & Performance has an article on Better Quality Through Software Reuse. The author recommends a reusable component size of 700-800 lines of code with about 3,000 lines of test code. Then you need to document the component both for the application designers who need to understand when to use the component and for coders who need to know component details. Then off to white-box and black-box testing. So while reusable components are a great idea, they take considerably more work to create initially...