Why so serious, er.. complex?

Question

I was just glancing at a related question list on this very site and it got me thinking. I see a lot of questions like:

• Should I deploy XYZ with my package or add a reference to some other path?
• How do I configure nant/cruisecontrol/etc.. to run my unit tests?
• Where should I keep my config files for unit tests in XYZ setup
• etc...

Now, when I develop (using .NET and Visual Studio), I choose a very specific directory structure:

• doc: contains all documetnation
• lib: contains compiled dependencies
• src: contains all program source and dependency sources
• etc: miscellaneous files related to the project
• bin: compiled program output

Generally speaking, if something can't be done within that directory structure, I simply don't do it. This includes unit testing, continuous integration, etc... In the same light, my entire program WILL run out of the bin directory with the exception of OS or network references. I refuse to introduce dependencies on the file system that don't reside in my program's root directory. I'm sure I'm missing out on some really cool aspects of development, but I've tried cruise control and I've tried nant and to be honest, as someone who works with a lot of small projects (200+ small projects a year) as opposed to a few (10-20) large projects, I can honestly say the simplicity is more desirable than some of the benefits of using these tools.

I guess my question is, am I just a simpleton or does it seem like certain things are just far more complex than they need to be? This whole "design so it fits all" mentality really seems to get in the way of getting things done at times.

Answer 1

I see your point about how people can over-complicate things. However, one thing to consider is that using "extras" are not always specifically meant to make programming easier. Sometimes, they're used in an effort to make it better in some fashion. By using these additional tools, you're trading simplicity for something else.

For example, using a unit testing framework definitely adds complexity to the project. However, you're trading simplicity for more error-free code (in theory).

It probably varies on a developer-to-developer basis. For someone like yourself, simplicity seems to be of the utmost importance. Perhaps this grants you greater speed and less time spent searching for solutions to configuration issues. But, someone else may be willing to trade some time fiddling with a framework in order to feel more confident that their code is solid.

Answer 2

200+ small products a year is almost one per work day. I don't think the problems people are having on large projects are going to apply to you.

I'm curious. What are all those small projects you work on? It sounds fun. But if I had that many projects to do per year, I think I'd be using Python, not .NET. Unless it's IronPython you're using. :-)

Answer 3

Generally speaking, if something can't be done within that directory structure, I simply don't do it. This includes unit testing, continuous integration,

small projects (200+ small projects a year) as opposed to a few (10-20) large projects

Assuming that you're working by yourself, your large projects ( < 1 person month ) would be called 'small' and your small projects ( 1 day ) 'tasks' in most shops. Large projects, such as the software for the joint strike fighter or government information systems are hundreds of person-years. Most of the small projects I've worked on have been 2-6 person months, and medium ones 1-4 person years.

I guess my question is, am I just a simpleton or does it seem like certain things are just far more complex than they need to be?

Certain things are more complex than can be created in one programmer month.

Continuous integration is probably not useful on projects of less than a month, as you don't have time to build up a system where you've got a large amount of un-integrated work.

Once you work on something long enough that it gets big enough to forget what some parts of it do, or on anything with more than one developer, unit tests give a good mechanism for stating the intended functional behaviour of the system in an unambiguous manner.

If you're configuring a piece of software for different deployments, and you already have good confidence in the software, then system level tests are often sufficient.