Simple v. Easy
The Iron Yard had us watch a talk about simple v. easy and how it relates to programming. While there was a lot of information that I didn’t initially grasp, I appreciated the general sentiment of the talk.
Simple is the opposite of complex. Complex scenarios can be broken down into simpler, and easier to understand segments.
Easy, on the other hand, is a relative term. Something might be easy for one person and difficult for another, depending on several factors including prior experience and exposure.
Thinking about easy v. simple is very useful when thinking about programming and software development. When I’m working on a project for the Iron Yard the easiest way for me to finish efficiently is by using knowledge that I already have, taking little to no time to plan, and hacking my way through it. If, in two weeks, someone else comes to look at my code (or even if I come back two weeks later), and want to make changes, this will be very difficult and complex. I won’t understand why I wrote the code the way I did and it won’t be obvious how to fix any bugs that have occurred.
On the other hand, if I started the project with the goal of keeping my code as simple and succinct as possible, I would be able to come back at a later date and have a much easier time making changes. The same should be true if someone who is completely unfamiliar with my project takes a look at the code. Even though the entire project might become complex, if I make put prior thought into the design, systems, and processes then I should be able to come back and break down the complex system into simple, easy to understand segments.
Something that is simple should be easy to understand, but something that is easy is not necessarily simple.
Planning before programming helps eliminate the risk of doing whats easy instead of what is simple and in the long-term, much more effective.
