Being An Elegant Business Programmer

11 September 2011 | talking about Programming

“I am a Java programmer.”

“I am an object oriented programmer.”

“I am an agnostic programmer, I can program anything.”

“I am a mobile programmer.”

When talking to software developers everyone is something. Today I am going to reveal what I am, creating a new category of programming, a completely new bucket of organization. Drum roll please.......”I am an elegant business programmer”.

computer geek image

Being Elegant

Ok maybe EBP is not the best name, I will work on a better one. For now, though, let’s define what it is. First let’s analyze the “elegant” part. Code can be a work of art or a tangled web of craziness. I consider code elegant if I can read it as I would a book. A well-written book reads smoothly, and uses words wisely to lead the reader along with the plot. Unnecessary wordiness may drive readers away. Similarly, with software development I should be able to start at the top of a file and read through the entire code at a consistent pace, not getting hung up on any section in particular, and not being flooded with unnecessary terms.

An example of “not so elegant” would be a 10 line sql statement just to return back a perfect sub-set of data, when a “Select *” would have done the trick. That 10 line statement often will cause someone reading the code to stop and spend a great deal of time dissecting. I am sure that block of sql took 100X longer to write then a simplified version that might have returned a little more data. Furthermore, that block of code is very hard to maintain and debug in the future.

I know what people may respond to the statement above with “performance is better with the ugly block of code”. You know what does not perform well? Software that never launches. Or software that launches with tons of bugs. Every performance decision should be made on “will my users notice the difference”. They will notice bugs. They will notice it takes forever for you to release new features.

Be a knowledgeable programmer: recognize when there could be better ways of doing something. However, when software is young, a focus on elegant, maintainable, bug free software is a far better approach.

Naming conventions: keep them readable. Anyone that has ever read my code will notice I use longer and more descriptive class, variable, and function names. Remember: your code should read like a novel. Don’t make your names so unreadable that no one can understand your code. Both Objective-C and Ruby have gone to great lengths to make naming conventions understandable. I try to follow suit.

Another less than elegant approach is being tough with your typing while you program, particularly in scripting languages. I really get annoyed when I see classes riddled with private and public restrictions. I really get annoyed when people go overboard with making sure every variable is typed just perfect. Yes, in some software this stuff really matters. In web scripting world this stuff does not really matter. It just makes you an OCD, control freak programmer.

Programming For Business

Now, for the second part of EBP. Developers often get trapped in making problems more complex than they really are. They often want to throw the latest and greatest bleeding edge technology at a problem. Developers are engineers, they are complex thinkers. This is all fine and dandy but there is a place and a time for it. The Google 20% time is a great example to be followed. Take 20% of your week and become really innovative. Play with bleeding edge stuff. Dive into deep complex thought processes.

Now, for the rest of the time, do what is best for your company. Most software developers work for a company or a client. Companies and clients are businesses that make money. I try to not lose focus on what really matters for the business: product, customers, revenue, growth, and so on. When making programming decisions I often start with the business reasons for what I am doing and make that a driving force. The computer science theory I learned in college is always second in my design making process.

Lastly, programmers often justify some complex design or bleeding edge approach by saying “I am thinking about the future, therefore I am thinking about the business”. Yes, you should think about the future but through small iterations. You should not slow down the growth of the business side of your company because you need time to build for the future. Get to the future through iterations and 20% time.

Elegant business programming is nothing more than 2 things. “Keep it simple stupid (KISS)”, and don’t let your computer geekness get in the way of the business execution.
 

tags: programming, business

blog comments powered by Disqus