No, you read that correctly. Simpleton, not Singleton is the subject of choice today. Recently a fellow developer was looking over some code that I had written.
He commented on it by saying, “Rob I just love looking at your code. It’s simple, easy to read, well-commented, and just makes sense”.
I replied, “Well that’s likely because I’m a simpleton”.
So jokes ensued with my friend asking, “Is that the design pattern you follow?”. I thought, well yeah actually I guess it is and thus was born the idea for this blog post.
I’ve read a good deal online lately about how the code that “just gets it done” is more valuable [generally speaking] than code that is elegant. I understand that point of view but to me, making that your “go to approach” smacks of laziness … just being honest there. I think the solution lies in elegantly simple code. See, in my opinion, there is a balance to be found between completely thoughtless code and completely over thought code. Really when you look at those two extremes they break down thusly.
Completely Thoughtless Code
This is code that is cobbled together using built-in wizards or snippets someone else wrote. No using wizards is for noobs, let’s just get that out there right now, haha! But there is nothing wrong with using snippets someone else wrote but too often, these aren’t given enough thought/testing to see if the snippet truly fits in with what a developer is doing. That can create a lot of maintenance headaches down the road.
Completely Over Thought Code
This is code that is so over thought, so over-designed, where it’s to the point that every “new” thing out there is in it. Some folks call this a resume-builder. Now, now don’t be cross with ol’ Rob. I’m all for doing a new cool thing because in six months you know you’ll be looking for a job. I get it. But don’t get crazy with. It’s bad developer-ju-ju to write crummy code simply to pad out your resume.
Don’t get so caught up in the tech and tools that you forget about the point of your application. Remember we’re all like Tron; we fight for the users.
“I think the solution lies in elegantly simple code.”
So over thinking the code can be a huge problem too. This is the other end of the pendulum’s arc actually and ends up causing [sometimes] completely thoughtless code to happen. In the Over Thought Coding situation, developers do this amazingly uber-complicated design, that only requires a single button push to “do it all”. And they think it’s “so simple” … when it’s really only simple to them. Then they leave the company. The new crew comes in and finds it to be .. shall we say .. a tad less intuitive than the authors expected it to be.
So the new devs, in scramble-mode, resort to snippet-hunting. This is generally due to the fact that there is no time to dig in and learn a complex system that is likely undocumented (because so much time was spent on code elegance that none was given to documenting the system). So scramble, snippet, compile, release becomes the new development cycle.
There are many other variables to consider here I realize (project management, team communication, etc) and we can’t get into them all here. We’ve all been there. So simpler approach, in the middle of these two, is warranted.
The Simpleton Pattern
[pullquote]That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. – Steve Jobs [/pullquote]
A good developer friend of mine has the following mantra when coding. A method or function should do one thing and do it well. – Frank Jones
See? That’s genius. Following that one guiding principle is the very first step in keeping your code readable and simple. So right there is feature number one in the Simpleton Pattern.
#1 Your Code Should Do One Thing and Do It Well
Having a single purpose for a class, function, method .. whatever .. is the cornerstone of the Simpleton Pattern. Honestly. If a function is saving data to the database, it probably shouldn’t also be checking for dupes or other types of validation. It should be dumb. It should know how to do it’s “one job”. Let’s put it into Texas hold-em terms, shall we?
- Hey, I got data [the flop].
- I throw it at the database [the turn]
- Read the return value from the database [the river].
- Then I throw the answer back to the calling function [the showdown].
- Whew, I’m bushed. [time to ante up for the next hand]
C’mon where else are you gonna get programming explained all poker-style? But that is true, see that save function didn’t handle validation, didn’t handle errors, didn’t handle any UI stuff. It had one job and it did well.
#2 Never Document What Your Code Is Doing, Document Why It’s Doing It
Pretty simple to understand I thought. I once heard good code comments explained this way and it stuck with me. When I started developing, early-on, I broke this rule all over the place. My code comments were always explaining embarrassingly simple things like a loop. Ever write comments like this?
[csharp]
//Begin loop through pricing objects
foreach (objPricing in loPricingItems)
{ businesslogic.updateprice(objPricing); }
//End loop through pricing
[/csharp]
Note: Ok I didn’t START my programming career in c-pound .. er c-sharp .. but you get the idea!
A better comment might have been:
[csharp]
//Updating pricing here right after new values have been supplied by the user.
//Pricing has to be updated to help facilitate real-time communication of data between users.
//That is why the save is done here, instead of waiting till the main save routine.
[/csharp]
See without this comment a developer might think, “hey this should be refactored, I’m going to move this out into the main save routine to cut down on hits to the database”. But this quick comment tells them WHY this is doing what it’s doing and why it’s HERE. In my old way of thinking, all you’d have gotten from me was that this is a loop and that’s pretty obvious without any commenting. I’d have kept it in my head that it needed to be in this particular spot to fulfill a business need.
Before you tell me that you’re not interested in writing comments for other developers, let me say this. That’s fine. Forget about them. Write them for YOU. Stop, I implore you, keeping all this unnecessary stuff in your head. Like Morpheus said, “Free your mind”. Comments for yourself, that just so happen to make sense to the masses, are one great way to take a load off of your brain.
The last point on this commenting-vs-no-commenting thing is … as a developer, ask yourself when you’ve had to look at someone else’s code and you’ve been lost. How many times have you had to wonder WHAT the code is doing? How many times have you had to wonder WHY?
I rest my case.
And lastly …
#3 Make the Breadcrumbs Big and Easy to Follow
Let me make this clear with a simple example. In a typical 3-tier ASP.net application, I have my front-end code, my middle-tier business logic, my database layer and the procs in the database. So here is how I would code myself some simple names to follow from the database to front-end.
Objective: Get the pricing items for conversion.
[plain]
Proc name: usp_GetPricingItemsForConversion
Database layer method: GetPricingItemsForConversion()
Business layer method: GetPricingItemsForConversion()
Code-behind for front-end: GetPricingItemsForConversion()
[/plain]
See how easy that is to follow? But you know what I’ve seen time and time again? Something like:
[plain]
Proc name: usp_GetAllPricingForGrid
Database layer method: LookUpPrice()
Business layer method: CallDB_GetPrice()
Code-behind for front-end: PriceLookup()
[/plain]
See how that is not easy to follow? Simple things like leaving a clear trail of breadcrumbs like this for lines of logic in the app is a huge plus. Silly example? Au contrare. It’s a real-world example. Establishing simple patterns for yourself like this will not only make your work easier but it will also make life easier for those that have to maintain your code later.
Conclusion
So what have we covered?
Well, I think we have covered three points that will certainly make your code-life simpler, both for your sanity, and the sanity of those who have to work on your code later. Following a simpleton-pattern approach just makes things easier all the way around. You get projects done, users get apps to use, and when they ask for changes, those apps are easy to maintain.
What are your thoughts? What advice do you have out there for keeping things simple?