software-dev

recent posts related to software development

The place to fight design wars is in new markets

“When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.

This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it’s hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.

So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you ... The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That's where you can win big by taking the bold approach to design, and having the same people both design and implement the product. ”

~ I hope to write more about this at some point, but for now this is a long quote from a Paul Graham blog post titled, Hackers and Painters

Software development process standard operating procedures

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.

“Dark Scrum: The case against the Sprint”

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?”

How I make very early software cost estimates (Part 1)

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:

Bugs in cross-platforms apps are driving me crazy

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.

fMRI software bugs upend years of research

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.

Glad that C wasn’t developed by advice of a large crowd

“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