Posts tagged Software Development
Complexity, Simplicity, and Elegance
Sep 7th
A friend and I were recently talking shop (over Xbox Live of course) and began discussing patterns we see when people get comfortable with what they know. There are a lot of programmers who are good and reach a certain point where they are continually writing what is, essentially, the same program for every problem they are solving. While this may seem to be an optimal solution, what it leads to is a loss of creative thinking and solutions that don’t quite fit the problem.
During the conversation I likened this to people from the 80s or 90s who never wanted to update their style and the analogy kind of stuck. This friend is updating his style in a big way; by taking a leap to a job where I have no doubt he will be successful. He said one key thing that stays with me every day. Even when you reach a place where you are comfortable with your style, if you are not constantly questioning your style or trying to figure what it is that you don’t know, there will be no true growth and you may never find the next level of solution to your problem.
A recent link that came across one of my RSS feeds pointed to this article, part five of a five piece interview with Ward Cunningham that took place in 2003. The article is titled “The Simplest Thing that Could Possibly Work” and explores simplicity in software design drawing from Einstein’s quote “As simple as possible, but no simpler.” This quote is very easy for people to use against you, especially when it is in the context of a solution they do not fully understand. The key is that the complexity of the solution is relative to the problem it is solving.
If you take your average web developer who is performing front-end work on an E-commerce site and stick them on the back-end of an enterprise service bus that is using an event-driven architecture, that developer will most likely think it is complicated. That perceived complexity is misplaced because a service bus is an elegant solution that was crafted by breaking through the complexity of messaging, loosely coupling back-end systems, and orchestrating it all in a way that meets the business process needs and solves the problem.
In his book “Pursuit of Elegance: Why the Best Ideas Have Something Missing”, author Matthew May broaches the search for elegance by defining it as the simplicity that comes after you break through the complexity. In order to reach that solution, you must understand the complexity, get tangled in it, and ultimately break through it.
By no means does this imply it impossible to build an overly complex solution. If you are trying to build a blog you may not have a strong case for using multiple services and a service bus. There are simpler solutions for blogs out there. However, if you are trying to connect autonomous services in a scalable way that allows those services to operate independent of the state of other services, then a service bus is probably a good choice. The complexity of the solution is relative to the complexity of the problem. When both the complexity of the problem and relative complexity of the solution are understood, the solution can then be held to the standard of “Simple as possible, but no simpler.”
This is where staying current, questioning yourself, and “updating your style” come into play. If you are not constantly seeking a better way to do something, trying solutions, questioning the solution, and trying it a different way, you will ultimately get stuck writing the same program to solve every problem. In some cases the solution may fit, but when it does not the solution becomes more complicated and does not fit the mantra: “Simple as possible. No simpler.”
Should You Fix Working Software? Part 2: An Answer
Jul 14th
In part 1 I posed the question, which undoubtedly seems like an odd one. How would you fix working software, because by nature it isn’t broken?
The fix I’m talking about is rewriting the software with updated syntax or techniques. Why would you do this? A few of my fellow LLF grads were snagged up by Google while we were all going through the LLF program. We were talking about the culture and one of the things they told me is that Google coders regularly go through the code base and update code with new syntax, remove dead code, or refactor code to be more efficient or understandable. I loved this concept, not because I think redoing work is fun, but because it pushes developers to keep learning and to make code better as they improve their selves.
Often as developers mature they understand the business better and that helps them understand the code better, which gives them an opportunity to leverage refactoring to make the code easier to maintain. But this type of growth only happens in a culture that supports it and there are far too many cultures where it is taught to leave code alone because it "works". I would argue that working code does not mean maintainable code, and when code is hard to maintain it is even harder to change. Change is the number one requirement of IT.
An answer is what I proposed, so I will provide an answer that should be both practical and achievable. Create a culture of growth and learning among your developers. Grow yourself and encourage them to. Raise the bar for them and set high standards. There will be failures; learn from them and grow together. Once you have a culture of self-improvement, perspectives will change and it will improve your teams skills and your software.
This answer is not a technical one because the problem isn’t a technical one. The problem is a people one because, software development is about the people. The people who use it and the people who write and the depths we push our minds to when writing it.
I once served under an executive director who, after a major IT success, told me to enjoy it but not to stop. She said "ride this wave, but be sure to find another one".
—–
Resources to help you and your team grow:
MSDN – http://msdn.microsoft.com/en-us/default.aspx
Code Complete 2nd Edition – http://cc2e.com/
Refactoring Resources – http://en.wikipedia.org/wiki/Refactoring
Object-Oriented Resources – http://en.wikipedia.org/wiki/Object-oriented_programming
Find a local .NET User Group – http://ineta.org/
Find your local Microsoft Evangelists – http://msdn.microsoft.com/en-us/events/bb905078.aspx
Should You Fix Working Software? Part 1: The Question
Jul 10th
A few weeks ago I did my first code review on work that I had no involvement with other than some initial brainstorming and high-level architecture. As I was looking at the code I only saw one or two things that concerned me but even those were not critical. When I typed up the review I realized that first and foremost I need to clarify that the software was working and frankly, it’s hard to argue with working software.
In this case the component was designed with good object-oriented principles and there was really only one place where I thought a particular class had too many responsibilities. The developer, who is pretty new to REJIS, was extremely open to the feedback and all in all it was a good experience.
This had me thinking, what if you were reviewing software which wasn’t designed using good object-oriented principles? If the software was working, what angle would you take to suggest changing the design without offending the author? This is a tough question because there are many organizations where the development teams have a mix of procedural minded and object-oriented coders.
My friend and colleague David Risko wrote about this in his post "The Elusiveness of Object-Oriented Thinking". His post highlights some of the challenges of bringing developers into the OO space. Fundamentally OO breaks many of the traditions of traditional procedural thinking. It is a mind-shift that can be difficult to make and in a mixed environment where you have those in an OO mindset and those who are not, the differences begin to surface more often.
So what about that 1,000 line class with 3 methods and if statements nested 5 deep? It works and it’s consistent. How do you show that developer ways they could improve it’s readability or flow?
