Is software development engineering or artistry?

This long running debate received new life when Steve McConnell gave a fiery reply to an IEEE Computer article titled “Software Development : What is the problem?“. Eric Wise has now stirred the pot with his post Rejecting Software Engineering.

Personally I wonder why everyone thinks they are an artist. I don’t care if you are a software developer, carpenter, or plumber; every profession thinks they are so clever that they deserve the title ‘artist’. This is a load of crap. True pencil and paint artists can create subjective works without any repercussions.

Expectations to create readable, maintainable, scalable, testable, documented, and flexible code are everywhere. We can not even commit to open source projects without being censored for quality. Developers get no bonus points for clever solutions, only for quality and useful solutions.

The number of ways we can solve problems through software is amazing. Of these solutions comes many unique and clever permutations; all representations of their creator – the developer. But acts of creation does not imply the right to declare ourselves artists. Musicians are artists that can have free spirited impromptu ‘jam sessions’. When was the last time you saw a developer express themselves in a free spirited impromptu ‘code session’? It just sounds stupid saying it.

Mathematics is considered a science, yet solutions can be cleverly constructed. So why is it a science and not art? Mathematicians (like developers) need to be confined to solving a problem in order to start creating.

Solving a problem is not art. Creation is not art. Being held to standards and expectations is not artistic. We are not artists.

Jay Kimble recently wrote a post titled Git ‘R Done coding. I will agree that there is a needs to be a trade off between expediency and maintainability, but it saddens me to see that a lot of people are blindly supporting this mentality without researching the dangers.

Morts and younger programmers may not have the experience to walk the fine line between responsible software architecture and ‘quick hacks’. As a result, this is a very dangerous message to those developers with not enough maturity to make these decisions (but are forced out of necessity).

A number of driving factors exist why developers practice unhealthy expedient programming techniques:

• Trying to match fictitious budgets or timelines
• Attempting to pull higher profit margins off of fixed budget projects
• Fighting potential embarrassment of not finishing on-time
• Egotists attempting to over-deliver

Walking this line is tough for even veteran developers. I would argue that this is because it is an art form in mostly client communication and compromising. But I digress…let’s stay with the situation where a developer has to make a client assumption on expediency vs. maintainability. What are the top 3 questions you would ask yourself?

1. Does the client appreciate Expedience over Stability?

For example, assume we are talking about auto mechanics. Would you rather have your car fixed faster but run the risk of breaking down, or have your car fixed correctly but be in the shop longer? A small survey at where I work reveled that clients would rather have 3 working features than 5 semi-working features. This seems common sense, but many developers forced to make assumptions will choose to create more features than fix the ones they have already coded.

2. Will the solution significantly destabilize if I make a hack?

Can your application handle another hack? Has it been a fortress until now, or has it slowly turned into a card house? This is the judgment call of the developers. Unfortunately, it is often incorrectly left to the client to decide. This is where the developer needs to be honest and propose compromises.

For example, a client requests a feature that will not easily fit into your current architecture. If a hack will not destabilize anything, a hack might not hurt. If you have to refactor code just to fit the hack in, you might be in trouble. In either situation the solution is simple, lay the cards on the table and when in doubt ask the client Question 1..

3. Is the client willing to compromise on this feature?

Most clients are not married to the features that they request, instead they are passionate about the domain problems that the features solve. Proposing new features that accomplish the same task can satisfy both client and programmer.

Other compromises can be made:

• Reduced Price
• Delivery of feature in next version
• Trade some features for others

Still not sure of what to do? When in doubt, error on the side of quality and aim for perfection. Anything short of asking the above 3 questions and you are making dangerous assumptions.

• Asshole Driven Development – A hilarious and honest play on our industry acronyms by Scott Berkun.
• Classic Mistakes Updated – Steve McConnell updated his Classic Mistakes list as originally written in the timeless book Rapid Development.
• In Programming, One Is The Loneliest Number – Great post on the dangers of programming alone.
• Spindrift – How many degrees of separation from reality is your sales team?
• Human Attention Does Not Obey Moore’s Law – A rant by Hugh that human beings don’t scale.
• VS 2008 Multi-Targeting Support – Scott Guthrie gives some insight into Orcas and its ability to build against all .NET frameworks 2.0 and above.