Posts in the “software-dev” category

Some long time ago I was working on a large software development project, and I wasn’t happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.

One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you’re doing as a business analyst. For example, here’s one of the guidelines I came up with after I learned about FPA:

If you can’t count the Function Points when you’re about to start developing a software project, you’re about to enter a world of hurt.

I used to be one of the three worst software development estimators in the world. Okay, I was probably *the* worst. I could not estimate the time or cost of a software development project to save my life. Then I learned about this thing called Function Points, and Function Point Analysis, and other common sense things, like the Law of Averages, and my estimating life is much, much better. I might even challenge someone to a contest one of these days.

Someone asked the other day if I've written any longer tutorials on software cost estimating and/or Function Point Analysis. Sometimes I forget that this site has grown pretty large, and things like this may not be easy to find with the current design.

To help solve that problem in the short term, here are links to two software cost estimating and Function Point Analysis (FPA) tutorials I've written:

Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

Update: Sorry, the Function Point Analysis application that was described in this article is no longer available. I may bring it back to life at some point in the future, but for now it’s offline.

Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.

The problem

Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.

The solution

I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:

From a Ron Jeffries article, Dark Scrum: The case against the Sprint:

“Let’s consider the Scrum Sprint. What’s the strongest case we can make against it? We’ve already talked about the fact that Sprints are not necessary to teams who are working well: pulling one story, and swarming on it, then another and another, works better, my friends and I believe, than Sprints. (There are good reasons to continue a regular cadence of planning, and certainly of review and retrospection.) But that’s not much of a case. What else ya got?”

While adding some AJAX autocomplete functionality to a new web application, I created a simple jQuery autocomplete example, using a PHP server-side script, and JSON to communicate the data from the server to the client. After creating that simple example, I thought I'd share all that code in a "jQuery AJAX autocomplete" tutorial here.

Before we get started, I'm going to assume you're familiar with basic HTML, CSS, and JavaScript programming fundamentals. It will also help if you've had a little exposure to jQuery, though that isn't entirely necessary.

I know remarkably little about Python and GTK, but from the two URLs shown in the source code below I was able to piece together a working, “Hello, world” screensaver. Well, calling it a screensaver is a stretch, because what it will really do is burn the characters “Hello, world” into your monitor; but at least I cracked the code on how to get this started.

To try this on your own Linux system running xscreensaver, first save the following source code somewhere. I’ll assume that you’ve saved it to /home/al/hello.py:

Over the last few weeks I’ve taken a little time here and there to put my notes on software cost estimating together, and the end result is a free, 100-page PDF that I’m sharing here today. The PDF covers most everything I know about the art and science of estimating the time and cost of software development projects.

At the moment I can’t think of too much to add to the book, as I cover a lot of ground in the book’s Preface, and in its “Three Lessons.” So, without any further ado, here is the download link for the book:

“How software projects actually ship.” Image from this Twitter page.

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

~ Bill Gates

I kinda-sorta like writing code with Sencha Touch and Ext, but I have to say that big problems you encounter with trying to use one tool to write code for multiple platforms are (a) bugs that affect one platform and not another, and (b) trying to write code to some common denominator — when that “common” approach doesn’t look native on any of the platforms.

I write this as various bugs in different cross-platform tools have driven me crazy lately. Some of these are related to Sencha, and some are not, but the end story is that I will tell any customer that if they have the money, they should pay to have native apps on each platform.

I’ve seen several articles about major software bugs (and a lack of testing) recently, and one of them is related to MRI/fMRI image processing. From this article at theregister.co.uk:

When you see a claim that “scientists know when you're about to move an arm: these images prove it”, they're interpreting what they're told by the statistical software.

A whole pile of “this is how your brain looks like” fMRI-based science has been potentially invalidated because someone finally got around to checking the data.

“You can use an eraser on the drafting table or a sledgehammer on the construction site.”

~ Frank Lloyd Wright

(i saw this quote on this twitter page)

“When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn’t developed under the advice of a worldwide crowd.”

~ Dennis Ritchie

“One of my most productive days was throwing away 1,000 lines of code.”

~ Ken Thompson

eXtreme Programming taught us that customers, programmers, and managers have certain “rights” on software development projects. As copied from this article, those “Bill of Rights” are listed below.

“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”

I was reminded of this saying when reading this article on Drupal 8 and Varnish.