I’ve done it. I’ve been guilty of ooh shiny development. You know, those projects where you use the latest and greatest library, tool, or infrastructure not because it’s the best thing to do but because it’s the cool thing to do. Continue reading ‘Oooh Shiny! Magpies don’t know what’s just enough!’
We all have our favorite books, the ones which we won’t let them pry away from our fingers until they’re cold. Those books which have shaped us, molded us, made us. The ones for which we’ve bought the first, second, third, and fourth editions. And not just because you’ve “gotta catch them all”, but because you genuinely enjoy the book and want to keep up to date with it.
Here are some of mine:
Continue reading ‘Computer Books which have made me who I am….’
I was just speaking with a coworker about JEP. In the course of our conversation I realized that in my list of the foundations of JEP, I had left off what is perhaps the most important one of all — Pragmatism. If I were to sum up and explain JEP in one word it would have to be pragmatism. Pragmatism implies using sensible solutions to solve problems. Pragmatism stresses being practical over principles or ideologies.
In short, are we trying to solve problems, or are we building edifaces to what Neal Ford refers to as the programming priesthood?
14Aug08
Quotes on Simplicity
“If a thing can be done adequately by means of one, it is superfluous to do it by means of several; for we observe that nature does not employ two instruments where one suffices.” — Thomas Aquinas
“Simplicity is the ultimate sophistication.” — Leonardo DaVinci
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the `Law of Least Astonishment’. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program. — The Tao of Programming, 4.1
The ability to simplify means to eliminate the unnecessary so that the necessary may speak. — Hans Hoffmann
A little while ago I’d come up with the following as a semi-serious description of Just Enough Programming:
Are you tired of over architected applications? Does infinite scalability imply infinite development time? Are you surrounded by applications whose sole goal is to be buzzword compliant? Do you suffer indigestion from the “extra sauce” that makes the management happy? Do the systems diagrams look like a redneck family tree?
If any or all of these are true, then you need Just Enough Programming™. JEP makes liberal use of Ockham’s Razor, cutting through the cruft and getting to the crux of the issue. It slices. It dices. It even juliennes. JEP fosters simplicity and elegance by seeking to make systems as simple as possible, but not simpler. Its goal is to achieve perfection by reaching the state where we have nothing more to take away. JEP is not just a methodology; it’s a way of life.
While it’s tongue in cheek I’d like to talk about the foundations of JEP.
Continue reading ‘Foundations of Just Enough Programming’
09Aug08
Just Enough Programming
I’ve been giving a lot of thought over the past months to the idea of “Just Enough Programming”. Agile manufacturing has led to Just In Time manufacturing. We also have Just In Time compilers. But I’ve seen far too many times where application architectures have been far too complex — where things are done, not because they’re truly needed, but rather because:
- It is the “buzzword approved” method.
- Architects and developers want to play with new toys.
- Features and functionality added because they might be needed someday.
- Premature scaling. If an application does not need to be infinitely scalable, then why add the overhead of making it so?
- Guru / Instructor / Net God / Writer X say that this is the right way to Y.
I’d like to make a case for applying a serious shave with Ockham’s Razor to these architectures, with a goal of creating “Just Enough Programming”.
Expect more on this topic in the weeks and months ahead.
- administrivia (6)
- books (1)
- Computers (2)
- css (3)
- eating crow (1)
- games (1)
- glassfish (1)
- gotchas (18)
- howto (2)
- idiocy (3)
- javascript (4)
- jboss (6)
- jruby (7)
- Just Enough Programming (7)
- life hacking (2)
- mini sagas (1)
- miscellany (1)
- monitoring (1)
- mysql (1)
- philosophy (4)
- php (1)
- programming (17)
- rails (7)
- rants (2)
- refactoring (1)
- ruby (14)
- tips (9)
- tools (2)
- torquebox (1)
- Uncategorized (9)
- UNIX (1)
- utilities (3)
- web (5)
- web design (3)
Flickr
