Topic: Software Development Best Practices

Requirements Set in Stone and Software Made of Concrete

Bernhard Kappe, Monday, December 21, 2009 @ 12:06 pm

Twas the night before Christmas, and 500 pages of detailed requirements had been produced. No line of code had been written, not even by a mouse.

It sounds great in theory: You produce requirements up front, getting them so detailed that they cannot be misunderstood, you vet them with a full committee of stakeholders who will be impacted (except your customers.) Then you give it to the developes. The result: you can get a really precise cost and timeline, you'll save on expensive development time, and your CFO will sleep soundly at night.

It's a nice fantasy, but it's wrong. It's a fundamental misinterpretation of how software development works. In fact, it's a guaranteed way of increasing your costs and producing bad software.

Here's why:
If you're developing software, you're coming up with a new solution to a problem, or solving a new problem all together. Otherwise, why are you building software, rather than buying it?

Traditional requirements definition processes are a spectacularly bad way of understanding stakeholder needs, and coming up with, conveying and vetting a solution for these types of problems. You will miss certain requirements, you will over specify others, and some of them will never get used. Your stakeholders will only be able to provide feedback of limited value until the working software is actually in their hands. At that point, you will finally start getting valuable feedback that you can push through as change orders.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

You Shall Know Our Velocity!

Bernhard Kappe, Friday, December 18, 2009 @ 7:09 am

With apologies to Dave Eggers, this post is not about traveling around the world in a week to give away $32,000, but about measurement and agile development.

One objection to agile development we get sometimes from people who have never done agile is that it sounds too undisciplined, unstructured and risky.

Would they say the same thing about lean manufacturing or six sigma?

They're confusing agile with cowboy coding.

In fact, like six sigma, agile software development is explicitly about reducing risk, measuring efficiency and continuous improvement.

The old management adage of “You can’t manage what you don’t measure” holds true in software development as well. If you have no feedback loops, and you’re not measuring and improving, you’re not really doing agile development.

The core measurements we use are story points and velocity.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Why Traditional “Fixed Bid” Software Projects Usually Fail

Paul Dittmann, Tuesday, December 15, 2009 @ 7:15 am

By now almost everyone has figured out that traditional fixed bid doesn’t work for software development projects, especially where effective, intuitive user interaction is a significant component of success.  Over time there has been a lot of effort devoted to finding the underlying reasons for project failure.  The Standish Group Chaos Report for 2002 found that 45% of features developed were never used, their 2008 Chaos Report found that typical software projects come in at 189% of original estimates (there is an obvious correlation there), and many studies over the years have concluded that an uncomfortably small percentage of development projects are viewed as meeting or exceeding expectations or providing competitive advantage.

Hidden implications of “fixed bid”

Although you need to provide a target budget to get projects approved, “fixed bid” for application development starts of with a faulty basic assumption – that user, functional and system requirements are fully known and documented in a way that enables efficient development. True fixed bid also implies “waterfall” development and two assumptions: 1.) you have completed a thorough, efficient design phase, and 2.) requirements won’t change during the development process. Neither of these assumptions are realistic.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Innovation and Treating Developers Like Adults

Dietrich Kappe, Monday, November 23, 2009 @ 5:28 pm

Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
-- Tom Smykowski

photo credit: sdminor81

I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:

It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

He's right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Software Development: Importance Doesn’t Always Equal Effort

Dietrich Kappe, Monday, September 21, 2009 @ 1:35 pm

I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.

To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Error Messages & Usability

Alice Toth, Thursday, September 3, 2009 @ 6:12 am

I was starting up one of the Adobe apps the other day when this somewhat troublesome message was displayed:

Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.

The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.

Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion: Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Does your project have Code Ownership Culture?

Sharad Jain, Wednesday, September 2, 2009 @ 12:09 pm

Code Ownership is a well known term in software development. Depending on how you define it, it may be a good thing or bad. When a developer sees code-ownership as him/her owning a piece of codebase that only he/she understands enough to make changes, it is generally a bad thing. It is only when everybody is free to modify the code with a sense of responsibility that he/she should leave the code cleaner than how they found it, it is a good thing. In my view, code-ownership is a good thing when viewed as a responsibilty as opposed to a right. I view it as a Collective Code Ownership where code is not owned by a single person or pair but is owned by an entire team.

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Kanban for Bench Projects

Dietrich Kappe, Monday, August 31, 2009 @ 4:51 am

photo credit: alq666

As a software development company, we mostly work on client projects. Occasionally one project doesn't start right when another ends. In that short interval, we would like to work on something useful -- in house products, R&D projects, etc.. Unfortunately, we can't run these "bench" projects the way we run a normal project. We can't do two or even one week iterations, because some folks may only be on the bench for a few days. So, how do you apply these resources efficiently? Here are a few tricks we use:

1. Divide work into very small pieces -- no epic user stories!
2. Keep your technology as vanilla as possible to reduce the learning curve.
3. Use Kanban to organize the work.

What is Kanban? There's some good explanations of it over at Wikipedia and InfoQ, but just like Agile and the feedback loop, it helps to know the basic principles so you can figure out how it will work for you. From the InfoQ article:

A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a "pull" production system, invented and developed as part of the Toyota Production System (TPS).

[...]

Kanban's aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. "Pull" means that the downstream workers withdraw or "pull" the parts they need from their upstream processes.

So, the basic principles are "pull" and minimizing "work-in-progress." Let's see how this applies to the bench.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Software Development and Wasted Motion

Dietrich Kappe, Tuesday, August 25, 2009 @ 3:15 am

All the good stories in agile software development start "three manufacturing efficiency experts walk into a bar..." But seriously, I think it's clear that software development has a greater affinity to manufacturing than to construction. So, its good to see the Lean and manufacturing folks get a little blog buzz over at AgileSoftwareDevelopment.com with Jack Milunky's post The 7 Software Development Wastes - Lean series Part 5 - Motion:

Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.

[...]

I have found in many organizations, especially software companies where there is a real casual atmosphere, it's easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

Sometimes being able to reference another discipline, like manufacturing, lends credibility to discussions with a stakeholder. More often than not, many consider themselves to be an expert on software development but wouldn't dream of challenging an expert on manufacturing.

Related Services: Agile Development, Custom Software Development

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Thinking about starting a SaaS or eCommerce business?

Paul Dittmann, Monday, August 24, 2009 @ 7:15 am

I’m approached by people every week that think they have a great “new” idea for a web startup.   The ideas run the gamut from those that aren’t yet technologically possible to those “new” ideas that I have received 10 similar calls on over the past year.   Here are some things to consider:

Think about the business need and revenue model first.  Who are the users (your “customers”), what is the application or service worth to them, how many of them are there, etc.   If you can’t envision generating a million dollars plus a year in SaaS (Software as a Service) revenue or in gross margin for an eCommerce business, it’s probably going to be an expensive hobby, not a business.

Make sure you can create a sustainable competitive advantage.  What are your differentiators?  If you have to say I want a site like “xxxxxx”, you are probably starting off on the wrong foot.   You already have at least one competitor with a customer base.   Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Software Development and the Construction Analogy

Dietrich Kappe, Thursday, August 20, 2009 @ 9:59 am

Dan Vanderboom has a thoughtful post up about software development methods. I especially like his takedown of the building construction analogy that is overused and abused in the world of software development:

[...] this is completely at odds with how homes are normally built.  People typically choose a previously-implemented design, and only customize superficial features like countertops, cabinets, floors, and railings.  Houses from this plan have been built before, and the labor and materials cost are known from previous experience.

Building software is usually more like constructing something that’s never been built before: the first sky scraper, the Golden Gate Bridge, or the Hoover Dam.  The requirements are unique, the pieces have never been assembled in such a way before, and there’s an inherent level of risk in creating something new.  When this is the case, the Customer needs the services of an Architect, not just a Builder who stamps out deliverables in a cookie-cutter style.

I would add two points to his post:

• One additional reason that building construction is not a good metaphor for software construction is that it breaks down along scale. You can construct a scale model of a house to validate the concept, but a scale model of the software is the same as the software itself. An application's size is measured in features, not feet. That's why agile development seeks to deliver a minimal set of features as quickly as possible.
• We've folded User Experience Design (UXD) into our agile process as a way of getting to value more quickly. Feedback in agile is important, but if you can improve the quality of that feedback, you converge on good features more quickly.

Related Services: Custom Software Development, Agile Development

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

What Software Developers Should Know Coming out of School – Part 2

Dietrich Kappe, Tuesday, August 4, 2009 @ 5:41 pm

photo credit: Yogi

At the end of part 1, I was frothing at the mouth about the "we're not a trade school" attitude of many computer science departments and professors. My take on it: even if teaching software development is not a priority, it's still not an excuse for doing a bad job. It's sort of like an art school only teaching art history, but refusing to show students how to competently apply oil to canvas.

Software Development Literacy: Application Types

When we get fresh recruits out of college or grad school, one of the things they struggle with, in addition to people skills, process, programming languages, and technologies, is a lack of literacy in application types -- Desktop, Web, Mobile, etc. If they've written them, they've written little toy applications to a professor's specifications. That's not good enough to get a true feel for what each type is about.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

What Software Developers Should Know Coming out of School – Part 1

Dietrich Kappe, Wednesday, July 29, 2009 @ 1:47 pm

photo credit: Artshooter

Pathfinder Development is a Software Development company. A large part of our workforce consists of software developers. Yet when we hire our interns and junior developers out of school, we hire Computer Scientists. That may seem like small semantic potatoes, but to me it is emblematic of the deep gulf that exists between the graduates that computer science departments produce and what software development companies like Pathfinder really need.

We are not a Trade School

There are a few things that really get in the way of Comp Sci departments producing good software developers. One of these is the "we are not a trade school" attitude. If you complain to professors that they aren't producing decent software development, dollars to donuts that this is the response you'll get. As I've mentioned before, my parents are both math professors, so I'm more than a little familiar with the culture of academia. In mathematics, having your work applied to something practical is the ultimate indignity. Real mathematicians scorn anything applied!

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

3 Misuses of Code Comments

Anthony Caliendo, Wednesday, July 1, 2009 @ 7:44 am

Photo Credit: by dpascoe

Not many people talk about good practices to use for comments in code. Many people see them as an extra or freebie, so not a lot of thought gets put into them. The truth is, though, that comments are a great tool for giving insight into the thought process when the code was being written. Unfortunately like any tool, comments can be misused.

Here are three of the most common misuses of comments which I tend to run into.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

Software Development

Summer Software Development Internship

Dietrich Kappe, Tuesday, May 12, 2009 @ 12:36 pm

photo credit: Paul L. Nettles

We're starting a software development summer internship in our Chicago office this year. If you're a college junior, senior or recent graduate who want to learn the agile/OO development ropes while developing really cool products and services and earning $20/hr per hour (you should pay for the privilege, right?), give the internship posting a look here.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development