I have recently had to solve a massive problem do with architecting a next generation platform for a commercial product that will steer the development team now and into the future. This task has a history of failure and now I have stepped up to try a make things right. Some of the problems I needed to address was:
- Architecture (to SOA or not to SOA)
- Migration plan
While brainstorming ideas about how to solve my particular problems, I went through a period of reflection. I questioned my self on all the practices that I would promote and the ones I would discard. I found this to be very healthy. Any good developer/architecture should regularly question their motives and approaches.
A lot of what we do its based on opinions, and sometimes based on other peoples opinions. I went about eliminating the opinions that were not by own. For example “Persistent arrogance”:
- Is this just an idealism?
- What benefit does it give me?
- What do I lose if I don’t have it?
- Is this something at sounds great in theory but in practice it not achievable?
- Is this something that someone has promoted to make them sound clever?
I did this over and over till I was happy that I had opinions that were my own. I reviewed programming and the industry in general and reflected on my own previous experience. One of the lessons I learnt was, it does not matter how clever someone is, what technologies you know or what pretty pieces of paper you have. Simple is best.
Just because its a dirty job doesn’t mean you need to get dirty!
I also find that top class developers generally make things complex and perceive that it is simple. Its worth having less junior developers around and present your code to them and get their feedback. Another trait that senior developers do it try to design and develop an elegance system, this leads to complexity, complexity leads to confusion, confusion leads to failure. The right thing to do it design and develop a system to be simply, then you get elegance.
What is Simple
Simple is relative, how do you measure simple? This is measured at many levels. The common place would be at code level.
Many books have been written about writing “Good” (again relative) code and writing Quality (relative again) code. Their are many things that make code “better” which makes it “simple” to understand and maintain: For example: (I have thought of many more points but a couple will do to illustrate the point)
- Name classes, methods and variables correctly and meaningful.
- Write methods that are small and concise.
- Follow the OO principles (SOLID).
- Use TDD with Test first design.
The next view would be how your code is structured and layered. If you have complex system that is all tackled up and depends on things that it shouldn’t, may be a few god objects and is a big sticky ball of mud. Then stretch it like a rubber band, pull the code about and separator it by the context that its used in. Of course, if you have a big ball of mud then I am pretty certain that you won’t have any unit tests that give you the feedback needed while you refactor. If you, like me have been unlucky and come to work on a code base that is a ball of sh** mess, then master refactorings and design patterns.
- Is the technology the right tool for the job?
- Are you using this tool, cos its someone above you tells you to?
- Do you have alternatives?
- How easy is it to recruit people with this skill?
- Its the technology you are using, just geeky and looks got on your CV?
Technology has a big part to play in simple/complex contest. Its worth reviewing what you are are using.
Does the architecture guide you or does it constrain you. Do you have read a book to understand the architecture that you are using? if an architecture is not flexible and you need to read a book about it then is not simple and not right.
Trends and fashion
This is linked to technology and my retrospective stated above. Developers my nature enjoy learning new technologies. Developers also try to find new smarts for the way they work. This is all great, but does need to be managed, otherwise your code base will be littered with spikes and random technologies. Before long your developers will not know what the standard tools or right the processes are. Technology and processes are in and out of fashion very quickly. A big dollop of common sense is required, review technologies and process in isolation and actually use the technology and try out a process rather than reading some blog and believing it.
Its easier to understand what is not simple.
Make it simple
“Simple” does have some concrete measures but their are other measures that are unique to you and your team. You need to identify what is important to you and analyse your code to see how it scores. Making things simple it in my opinion, the most important design goal.
A point about Design patterns
I have heard people slate design patterns, i personally i love them, but some/alot of people misuse them and thats whats has started the negative press. The rule with design patterns to identify a pattern in the code not to put a patterns in the code that don’t fit. I find the power of patterns is the vocabulary. Its great describe a class’s purpose in life when stating its responsibility, for example “its an adapter” or “its a factory”. All things in moderation.
Keep it Simple. A easy principle to understand, but often the hardest to implement because out actions are to learn bigger more complex technologies and processes that keep pushing our careers to supposed new heights. It doesn’t matter how big someone’s brain is, can you develop code that is simple?