The great thing about art is that it is all about the end product. The reality of the journey is obscured through layers and layers of oils, acrylics or whatever medium. Some critics will analyze technique, but the truth is all evidence of rework has been removed. All you have is the final product, and for better or for worse your opinion about it. If only development was like this.
However it is not. Us as developers live in a world where the core of your creation is exposed. From the shiny façade right down to the bowels of the implementation, every aspect of it is open to inspection and criticism.
So what does all of this have to do with the topic at hand? Well quite a lot actually. You see, most developers are perfectionists, or at least like the idea of being a perfectionist. So we read. And read. And read. We are expected to know business, business process, the latest techs and tomorrow’s techs. We have to foster an intimate relationship with knowledge, not only to sate our own curiosity, but also to survive in the game.
There is however an unseen danger in reading, more specifically high level philosophical texts on design, which is, inherently like art, subjective. For the sake of brevity I will refer to these texts as “books”. The danger is we very seldom get to ponder the points we read. Sure we process and understand, but we seldom question or extrapolate to real world scenarios. As such, more often than not a book smart developer is seen handing over their mind and creativity to the books author. The book smart developer spends more time memorizing the book verbatim than trying to process the “essence” of the message.
Technical books tend to be accurate. Sure there might be a bug here or there, but by in large they are spot on. And they have to be. This brings me to my first point in why book smart developers are bad developers. Technical books are an exercise in academia. Being subject to industry peers, they have to be right on the money. They drill down into their subject matter at nauseum, and are not allowed to waiver their opinion lest they relinquish the position of the “authoritive resource”. The problem now is the book smart developer has placed substantial investment in reading the text both in time and money.
Investment has a strange psychological side effect, once someone has invested in something, they don’t want to back out. There are many studies on this, one of the biggest being the subprime crisis in the US, and anyone who has studied mathematics will be able to tell you about Gamblers Ruin. As such, the book smart developer tends to adopt the attitude of “this is the way” and in doing so becomes a disciple of the author.
Onto point number two. I am not sure if anyone noticed, but during this electronic age, everyone forgot to upgrade books. The technology predates pretty much most things and hasn’t evolved much. I am not talking about a new eReading device here. I am talking about the communication style. It is one way. Half duplex. And it blows. One-way communication is opinionated, un-engaging, and dictorial. Couple this with the book smart developer, and you have the ultimate mind control device. Heck you might as well give away a free packet of Kool-Aid with every purchase. But we can’t blame books. They got one shot to get it right. Unless they push their message across in one reading, they have failed. They are medium constrained. Book authors get this, sadly book smart developers don’t. You see in every opinion there is some give and take, this normally comes in the form of some negotiation until an amicable understanding is in place. Usually in any form of negotiation, the initiator has to overstate their case, and then whittle it down to a point where both parties are happy. This principle is applied to teaching as well as bargaining. Books do not negotiate, nor do they care for your level of understanding on the subject matter. If the book smart developer has missed the point, well let’s just say the book doesn’t care.
Onto point number three; on completion of a new book, the book smart developer has an innate need to decorate every conversation with buzz words and terminology. While buzzwords may go down well at a tech convention to make you look good, they do very little in the way of educating others. As developers, in this fast pace environment, we have the civic duty to disseminate and pass on newly acquired information on to our peers. Lexically relevant buzzwords are completely counterproductive in this regard. If the person you are educating knows the buzzword, then typically they know the subject matter. Again it blocks the “essence” of the message. Buzzwords are all encompassing summaries; if you using buzzwords whilst explaining something, you are failing at communicating. Book smart developers tend to use buzzwords to shroud their lack of understanding in the subject matter. When challenged on these topics, you will see them characteristically make a dash for the reference material.
Point number four is more of a side effect of being a book smart developer. Book smart developers quickly loose what I think is the most important skill a developer has; the ability to infer and adapt. The books smart developer is the guy who is constantly trying to get the problem to fit the mold, instead of taking what they know, and adjusting it to fit the problem domain. Martin Fowler groupies tend to slide into this category quite nicely. He is the guy that tells the product designer it can’t be done (removing time and money from the triangle). Early on in my career while working for an investment company, our rather insightful CEO gave us a compelling presentation, during this he put forward a statement that has since become my mantra, it goes something like this: “Who makes the f&^king rules”. Just cause the book says do X, Y then Z, doesn’t mean you can’t slip W in there somewhere. If development was so cast in stone, then why haven’t we seen stability in it as in a discipline like accounting which hasn’t seen innovation in centauries?
Book smart developers fit into two categories. There are those that talk the talk and those who walk the walk. Both are doomed to fail.
The talkers however are the lesser of two evils. They are the ones that claim “We must be agile” then go on to tell you they run a 6 month sprint. They are the ones who cry at meetings “We must be domain driven” Then go back to their desk to carry on working on cross cutting layers. Basically they have missed the boat. Unless the book explicitly states it, it isn’t so.
The walkers are a more nefarious bunch. They are the types that implement a pattern with surgical precision. They are an ardent hard working bunch who are passionate about code, but do not give them small problems to solve. You see, if you study anything enough, it becomes a science. And if you don’t believe me, find a group of joggers and ask them “Which is the best way to tie my laces?” Likewise take a small problem that should normally take a few hours to do. Give it to the walker, and tell them they got a week to do it. They will take a week, and deliver the most convoluted, over engineered piece of code imaginable. It will work and it will be one hundred percent academically correct. Extrapolate this to an entire system, and well you get the picture; a “perfect”, un-maintainable and un-scalable mess.
Sadly, as developers we have all at some point in time have fallen foul to BSD syndrome (my first coined buzzword, someone open a wikipedia entry.). So what do you do?
Well a good start is diversifying opinions. Take the age old debate of stored procedures vs. in code queries. Truth being told; they both have their place. Don’t argue the philosophy of each approach, but rather the practicality of each.
Acknowledge that no solution is perfect. Like
art, there is always one more brush stroke to put in place. The real accomplished artist knows when to put the brush down. Don’t over analyze (Over, being the operative word here)
The cake is a lie. As developers, Greenfield development is our holy grail. However these sorts of projects are few and far between. While most texts revolve around Greenfield development, broadly speaking very few teach how to retrofit their approach to existing, monolithic systems. Ironically these systems are the ones that need the most help. As such it is pointless trying to implement an approach down to the letter. “SCRUM” doesn’t fail, “Agile” doesn’t fail. It is the change management, lack of understanding and unwillingness to modify the process that failed.
Stop being arrogant; you a developer, we are arrogant. Stop it. Saying “I don’t know” is a great way to learn new stuff. Remember, while your mouth is moving you are not listening. This will open up a fantastic learning technique to substitute books, I call it conversation. More information can be gleamed in ten minutes of engagement that and hour of reading. Engage in forums, twitter and all the rest.
There are no rules; just good and bad decisions. Don’t let a book dictate policy to you. Take the good bits; leave out the ones that don’t work for you. However always remain cognizant of your ability. If you have no experience in the field, I would say lean on the text a little more.
The world is not black and white, so embrace the shades of grey. As humans we have a built in mechanism (heuristics) that clamps fuzzy concepts to our closest understanding, this kind of goes against the natural order of things. We need to stop being so pedantic in our thinking and more fluid in our decision making. As stated before, a book does not know of your specific situation, or worse still, your heuristics have incorrectly interpreted the books message.
I have actually experienced this. A developer had implemented a processing routine in code that took several hours to run; it was done in code because “that’s where business logic goes”. It could have been implemented on the database to be run in a matter of minutes, the individual was adamant his method was right, and technically he was correct. Expect there was a problem, the business case was failing, and there were not enough hours in the day to process the job. It is this dogmatic thinking that leads to bad systems. Sadly that naïve young developer was me, and I am going to chalk that one up to experience thank you very much.
My last tip for developer Nirvana is to not have any investment in your code. Having the mindset of “I have don’t this once, I can do it better if I do it again” goes a long way to achieving this. Being able to scrap a few hundred lines of code at will is almost liberating. It also falls in line with the Agile/SCRUM/Lean/TDD/Buzzword paradigm in that it makes refactoring second nature; (And I mean proper refactoring where you decouple dependencies, not simply “right click -> extract method”). It also opens you mind up to different approaches and you tend to embrace change a lot easier.
Slappy's Blog 