I've read with great interest the analysis of the Duct Tape Programming blog post by Joel Spolsky.
Let me start off by saying that I have read Joel on Software off and on since it started. My initial thoughts were that Joel was right on some things and wrong on others. At the time, he just read like everyone else with an opinion. I could take it over leave it. I've always disagreed with his whole use of Wasabi. Who in their right mind would ever write their own compiler?!? However, one thing that I would agree with is the focus on shipping products. Why do something that doesn't directly go towards shipping a product?
I've read with great interest the posts for and against the ideas in the post. Here are a few of mine:
- A subset of developers/technologists like to solve the infinite scale problem. These would be the the people arguing about using titanium or composite materials at the starting line. The correct choice can be used to solve the problem that your users are having. Are you trying to get a web site to scale to 100,000 users per day, 10 million, or 100 million. Different end cases will guide the choices you should make at the beginning. What if the application is for internal to a business and needs to be used by 500 concurrent users?
- Everything looks like a nail. A few developers run around with this idea that they have a solution to everything because of this one silver bullet/magic technology that they have learned. Very rarely is the solution to my problem exactly what you implemented somewhere else. Solutions to a problem are rarely uniform from one place to another.
- Solve every problem that they could ever need. Do you do Oracle programming? I mean real programming against the database engine? Have you ever looked at the Oracle Management Console? Do you know about all the memory pools it has. Have you seen all the knobs and switches it has? There are a lot of them. Knobs and switches are good for being able to infinitely tune a product on various platforms. Unfortunately, infinitely tunable means infinitely complex. Many solutions don't need infinite tunability.
- Solve problems today. Joel has a goal, which is to ship products. By shipping a product that solves a customer problem, they will give you money (hopefully) for that product. With a web application, updates to the product are easier to deploy to the customer. Don't delay a solution to a customer unless it is necessary. Don't put processes in place that delay shipment unless the process has value.
My views are along those lines, but I would like to throw in a few thoughts:
- TDD. Testing is good. Test a product. Test a solution to a customer. I have to fight this problem I have, which is that I want to show something to a customer before I've fully tested it because I want to the customer to see that we're solving their problems. I couldn't agree more with the people that say that some form of automated testing is good. However, that message of needing some automated testing is being muddied by the people that are barking (yes, I said barking) that if you don't fully embrace TDD, and its message of having a testing framework put together before writing code, that kittens will be drown and that all life with cease instantaneously and every molecule in your body will explode at the speed of life. Someone on twitter, I don't know who nor do I remember who, recently said that those that implemented TDD saw an 80% decrease in bugs and saw a 30% increase in time to shipment. I think the 80% decrease in bugs is a big selling point. I think the 30% increase in time to shipment is a negative. With the customers I deal with, they are not willing to take the 30% increase in time to shipment. The cost to roll out a web application is so low, they are willing to deal with the increase in bugs to get the product quicker and to rollout additional versions to fix the resulting bugs. If your customers are different, then I'm glad. I wish I had them.
- ORM. ORM is kinda cool. The idea is to take data in one format, typically database, and put it in a format, typically business objects, that an application will work on, then do the reverse. Databases tend to work based on set theory. Programmers tend to be procedural. ORM attempts to cross those two divides. I think that's a good idea, except that now another layer is being added to getting at an application's data. I would estimate that 90% of problems regarding application performance are in working with data, now, we're knowingly adding another layer between an application and its data. Once again, if your customers are okay with that, great. My customers tend not to be okay with this, infact, we got one of our main customers because someone had mucked up an attempt to do ORM and caused all kinds performance problems. Ted Neward has some good ideas about the problems with ORM that I'll direct to his blog - http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
- ALT.NET. There's just no getting around the conversation about ALT.NET. I think the concept of getting a set of really good solid principles to work on is a great idea. My development principles are based on my experiences. I built netster.com and it ran for the longest time on one server. Under peek load (3-4 pm on weekdays), it generated about 125 asp requests / sec. We could handle that on a single Win2k server with 4 gigs of ram and 2 processors. The database and web server ran on the same server. Every asp request made at least one query against the database. At another customer, I took over an app that couldn't handle 5 concurrent requests when running on its own dedicated server. When I asked the original developers why they did things the way that they did them, their response was alwasy "That's what you are suppossed to do." I finally have gotten the go ahead to rewrite the customer's app, but they have budget issues, so its still under development. The lesson learned from this is, what are good solid development principles to you and your customers might not be good solid principles to me and my customers.
At the end of the day, on the two types of programmers that Joel mentions, The duct tape programmers are consulting, small startups, and those trying to get something going today. They have to get things up and going quickly. The guys that are arguing about titanium and composite materials at the starting line are needed at Microsoft, Oracle, IBM, and other major companies producing product for resale. However, when the guys arguing about titanium and composite materials intrude on the consulting world, all I can think is that
I need them to go away, get back on that wall, and get out of my way.
Thanks for reading. I'm sure that there are things that you agreed with, disagree with, or outright hate it. I'm sure I'll have additional thoughts on this topic, so stay tuned.