The Agile Method and Other Fairy Tales: QED

Self-proclaimed “software economist” and “international consultant” David Longstreet posted a twelve-page paper (in PDF format) called The Agile Method and Other Fairy Tales today. I thought the paper was a joke when I started to read it, but I believe Mr. Longstreet’s over-long and poorly-written paper is serious. Software developers should read the paper, or at least skim through it. Whether you practice or believe in agile development or not it’s probably good to see some of the silly arguments and misinformation that Mr. Longstreet is pushing before your executive team hires him to speak at your company.
Continue reading

Keep Legacy Databases Away From Your Code

Unless you are lucky, or haven’t been programming for very long, you’ve probably had to write code to work with a “legacy” system. The recruiter promises you’ll be doing all new development using the latest cool language. It may take a while for you to find out that all of the enterprise data and business logic lives in a poorly-understood, unmaintained system written in some language you’ve never heard of, running on the big beige box in the corner of the server room that has tape over the power switch. If the software vendor is still in business they can’t support the system, because it has been modified so much it can’t be upgraded to the latest release. Management has a project underway to find a replacement, but until then all new code will have to work with the zombie system.
Continue reading

Jack Of All Languages, Master Of None

Mastering a programming language takes a long time. The only way to do it is to read and write lots of code — lots of different kinds of code so you have to learn every feature of the language. Doing tutorials and following toy examples in books gives you an idea of what a language looks like, but it’s a long way from mastery. Learning to program probably takes ten years. Mastering a programming language shouldn’t take that long, but it takes longer than a few late nights.
Continue reading

Introduction to Abject-Oriented Programming

Abject-oriented programming is a set of practices for encouraging code reuse and making sure programmers are producing code that can be used in production for a long time. The number of lines of code in the application is a common measure of the importance of the application, and the number of lines a programmer can produce in a day, week, or month is a useful metric for project planning and resource allocation. Abject-oriented programming is one of the best ways to get the most lines of code in the shortest time. Continue reading

Do as I say… more on bad sample code

I came across this in the Flex 2.0 documentation:

You can define properties for your components by using setter and getter methods. The advantage of getters and setters is that they isolate the variable from direct public access so that you can perform the following actions:

  • Inspect and validate any data written to the property on a write
  • Trigger events that are associated with the property when the property changes
  • Calculate a return value on a read
  • Allow a child class to override

Continue reading

Learning by example: how bad code propagates

Studying code is one of the best ways to learn about programming. Experienced programmers use published algorithms and sample code; writing everything from scratch is foolish. Less experienced programmers often start with code they find in a book or on a web site and tinker with it to learn and solve their particular problem. Casual programmers cobble things together from code samples they don’t understand. It’s easy to find amateurish Visual Basic or PHP or Java code to make fun of.
Continue reading