Why does software development take so long?
Every year, thousands of software development projects are developed. In most of these applications (especially line-of-business applications) you will see a lot of the same UI patterns:
- When the value in one dropdown changes, the list in another dropdown needs to change
- Two list boxes with arrow buttons that allow you move items between the lists
- A grid with add/edit/delete buttons that allow you to manipulate the list
Most applications have other common characteristics, like:
- The concept of a User that has to log in, reset their password, and change their password
- Some concept of security roles
- Loading objects from a database by ID
Every project also has housekeeping tasks, like:
- Setting up automated builds
- Copying files to a QA site after a build
- Coming up with a way to create a development copy of the database
The problem is that on every project, it seems that way too much time is spent getting this stuff to work. Why??
These are solved problems. We’ve all solved them before. But we end up re-implementing the same stuff over and over.
This is a problem. Making an AJAX call to update the list in a child dropdown when the parent dropdown changes is not rocket science. I don’t want to write this code ever again. I want to write stuff like this:
State: <%= this.Select(model => model.State)
.Options(Model.StateOptions, opt => opt.Id, opt => opt.StateCode)
.UpdateOptionsFor(model => model.County)
.WithAjaxCallTo(“/state/GetCountiesInState”) %>
County: <%= this.Select(model => model.County) %>
(I’m using the MvcContrib HTML Helpers here.)
You write the code to implement this fluent interface once, and you don’t ever have to write it again. That’s the way that it should be. Every time you do something, you should be trying to find a better way to do it so that you can do it better next time.
A lot of people have already done lots of work for you, and you should take advantage of it. I’m talking about things like this:
- Using the built-in ASP.NET Membership stuff instead of rolling your own code to do Forms Authentication
- Using Rails scaffolding to create your website
- Using styling and controls from jQuery UI
- Using convention-based MVC frameworks (e.g. Rails or ASP.NET MVC + MVCContrib)
- Using the auto-mapping capabilities of Fluent NHibernate instead of writing mapping files or CRUD stored procedures
- Use S#arp Architecture as the framework for your application
Every developer should have a toolbox of code that he/she can draw from so that you can avoid being a plumber and spend your time doing valuable things, like writing business logic, designing user interfaces, and other things that you are being paid to do.
Jon,
Great points all the way through.
My “however” though, is that bullet point 1, the ASP.Net Membership stuff…we had a recent project where we wanted to use that, but a client decision kept us from it. Integrating another membership app just wouldn’t work. Granted that’s just one case, and one I wish we didn’t have to deal with.
Also, the tons of brownfield projects we seem to inherit, a lot of these decisions have been made, and we get to deal with the consequences. It seems our biggest hurdle is still “just get it done,” rather than getting it done right.
How well would the asp.net membership integrate NHibernate. Thats my main problem with using that one particular piece. User interface elements and toolkits are interchangeable, but Users are domain level items i’d like a bit more control over.
@joe,
I think of the membership Users table as separate from my Users table. For one, I don’t like to use Guids as my primary keys because I think it’s a pain.
The ASP.NET Users table ONLY deals with login related stuff. So I’ll have a separate Users table that looks like this:
create table Users
(
UserId int not null primary key identity(1,1),
MembershipUserId uniqueidentifier,
FirstName varchar(30),
LastName varchar(30)
)
The ASP.NET membership database comes with stored procedures for doing everything, so I should be able to just use those stored procs for all access of the membership tables. If I absolutely had to, I can map the membership tables to entity objects pretty easily with NHibernate.
My separate Users table will get loaded with NHibernate and is my real domain object.
This may not seem like it’s as “clean” of a solution as if you wrote it all from the ground up. But this way you don’t have to spend the couple of weeks writing all of this stuff yourself. If you have a valid reason for writing it all yourself, by all means go for it. I’m just trying to find a way to get things done faster, and using ASP.NET membership doesn’t muddle things up so much (IMO) that it’s not worth using.
Look at some of the things you listed, some of it just came out months ago! Every time we code something it is like re-inventing the wheel that is why it takes so long.
It always takes so long because with each decent sized project the technologies have moved on and you have to learn how to take advantage of the new ways – if you try to apply your tried and true method of a year ago, you often end up digging yourself into a hole. Perhaps just as importantly, each new technology has it’s own suite of nuances that you need to learn to work with and pitfalls that you need to learn how to work around.