Simple != Poor Quality, period!
time to read 3 min | 422 words

Casey commented on my post about ALT.Net and the Enterprise, and we have a good discussion going on there. But something he said triggered so many red flags that I had to go breath into a paper bag for a few moments:

many 'enterprise' teams have to take whatever body count they can get to satisfy the management. And in that case you have to keep things really simple (and by definition produce poor quality code).

He later went on to expand what he think is simple:

In case I expressed myself badly ... by simple in that context, I mean simple as in "mostly drag and drop", no IoC, no inheritance, no composition, lots of "standard things" like EAAB, and most code in the aspx.cs files ... because that is as far as most developers understand code.

"simple code" in the context I suspect you mean it is probably as I would define it... which is the hardest code in the world to write. The simpler the code is, the harder it is to write.

High quality code is simple, elegant and to the point. Keeping things simple means making it easy to go the right path. Thinking that keeping things simple is by definition producing poor quality code is a mistake.

I am afraid that I can't really find any simplicity in "mostly drag & drop, most of the code in the aspx.cs".  In fact, it is far more complex than the alternative, because you have to juggle so many balls at the same time.

Here is a piece of simple code:

[Occurrences(OccureEvery.Day, At = EsitmatedRunTime.MidMorning, RunAtHolidays = false)]
public class SendSmsTwoDaysBeforeEventStart : ScheduledTask
{
	public override void Execute()
	{
		ICollection<Event> eventsInTwoDays = Repository<Event>.FindAll(
			Where.Event.ScheduledDate.Between(InTwoCalendarDays, InTwoDays) && 
			Where.Event.Participants.With(FetchMode.Join)
		);
		foreach(Event e in eventsInTwoDays)
		{
			SendNotificationSmsToAllParticipantsIn(e);
		}
	}
}

It is easy to write, easy to read, and it is stupid code. You can write & test this in a short amount of time, and it lends itself greatly to a check list approach. "Here are the batch processes we need to build right now, here is how you build a batch process, let me know if you have any issues and when you are done". Very simple code, quite elegant, if I say so myself, but nothing that you need to really think about when you build it.

Keeping things simple means higher code quality, period. Making them complex any tiny bit over the necessary, and your code quality will plummet.

Tweet Share Share 44 comments
Tags: