Software Engineering posts

Design, Art, and Science In the Context of Software

2013-09-08

I was listening to a recent Hanselminutes podcast where Scott Hanselman speaks with Natasha Irizarry about User Experience (UX) (you can find the podcast episode here), and a very interesting debate got started in my head.

Worst Practices: Confusing an Estimate with a Target

2013-06-17

In software engineering, there is a subtle but significant difference between an estimate and a target. This difference is often overlooked, and can easily lead to conflict that disrupts the progress of a software project. With all of the other potential causes of disruption, software engineers have to eliminate as many risks of this type as possible.

The Ambulance Down in the Valley

2013-05-27

A while back, I was discussing some of the nonsensical actions that people take in the software industry with my parents during a visit. my mom told me to look up a poem called The Ambulance Down in the Valley. I wrote it down and forgot about it for months because I was in the middle of the last semester of my Master’s degree. I finally got a chance to look it up, and it really is a beautiful illustration of the strange way we look to solve problems sometimes.

The Danger of Building a Product on Someone Else's Service

2013-04-10

Do Horizontal Lines Make a Good Symbol for a Button?

2013-04-10

Recently, a friend of mine asked me what I thought of the “horizontal lines” symbol that is being used more and more frequently to indicate where to click or tap to get to a navigation menu. I really had to take some time to think about it, because I realized I don’t usually pay very close attention to the symbols used on buttons in the apps that I use.

Why "Bug Free" is Impossible

2011-08-23

One of the most common misconceptions about software testing is that, once a program or software system has gone through testing, it is free of bugs. If you accept this assumption, it logically follows that, if any bugs are found by the end user, the software was not properly tested. Both of these statements are absolutely false.

Worst Practices: Thinking You are Done Learning

2010-07-20

In the field of software engineering, you are never done learning. That should probably be one of the first ten rules of the profession.

Agile Requirements Gathering Risks

2010-07-16

The biggest strength that traditional requirements gathering techniques have is their structure. When using these methods, the Requirements Engineer (RE) is applying a formula, pure and simple. There are outlines to follow and forms to fill out, which makes the job of RE more accessible to a larger group of people.

Valve Got it Right

2010-07-11

On May 12, 2010, Valve made its Steam platform available on the Mac. There are a few key points of the way Valve chose to do this that show design decisions which support the needs and desires of the customer base. All too often, software companies do things the way that is easiest for them, at the expense of end user satisfaction. The Steam platform has grown in a way that exhibits the exact opposite: Valve gave themselves extra work, and sacrificed some potential revenue, to build a platform that caters to the users.

Tested or Not?

2009-07-22

A software system’s “tested” status is an interesting thing. Sometimes, in a schedule crunch, the decision makers may decide to cut back on testing, hitting only the most commonly used portions of the system. Almost inevitably, when this is done, a bug in one of the less commonly used parts of the system gets out.

Making Better Use of Patterns

2009-07-21

Software Patterns are very useful. They provide us with common solutions to related, but distinct, problems.

Benefits of Analogies in Software Architecture and Design

2009-07-21

Analogies are often used when building or discussing the architecture and design of a system. I think there are two main benefits to this.

Analogies as Abstractions

2009-07-21

Analogies are an effective way of communicating knowledge of one domain by mapping the domain’s concepts to another similar domain that is known by that person. In this way, a person can gain understanding of domain B through their existing knowledge of domain A.

Sinking the Titanic

2009-07-06

Imagine, for a moment, that you are Poseidon, god of the oceans. The RMS Titanic is sailing in your waters, and you don’t like that. You decide that you want to sink the Titanic and make an example of her for other sailors of the world, so you order your minions to construct a giant iceberg that will crack her hull and sink her.

Abstraction in Software Architecture

2009-05-30

One of the important parts of the essence of software architecture is that it is an abstraction of the actual code of the software system. What’s interesting about that is that it means software architecture is an abstraction of an abstraction, since the code we write using modern programming languages is just an abstraction on top of machine code. Just how many layers of abstraction have we accrued over the years that Software Engineering has been growing up?

The State of the Art

2008-11-02

There is an enormous discrepancy between our understanding of Software Engineering as it should be practiced and the ways that we actually practice Software Engineering on the job. We know that proper designs and methods can save tens of thousands of dollars down the line, yet we continue to make messes of our systems. Why does this happen?

Recording Real Time to Failure

2008-10-29

If the mean time to failure is an important statistic, why only measure it during development and testing? Building a small, anonymous crash reporting tool into your application can provide you with a wealth of information and can help you to improve your overall quality. Of course it would be wise to make sure the users are aware of this tool, wiser to give them the ability to enable and disable it as they see fit, and wisest to leave it disabled by default.

Baseline Systems for Testing

2008-09-16

I haven’t researched this, so I don’t know if it’s already an established practice or not.