Filed under: Development
Days ago my colleague forwarded me a post from Jason Fried at 37 signals, the company who created Ruby on Rail, talking about the story of how they designed and implemented a new product feature. It’s inspiring. To me, it recalls of two lessons I’ve been taking for long during my development career: small problems over big problem, small solutions over big solution.
People love GENERIC stuffs
It is always a habit of people, essentially developers, to think big ahead. But why? Cos it is commonly believed that every body can do small solutions but only the smarts can think big stuffs – designs crafted to “potentially”do many things ahead with minimal amount of effort. So physicists have been working for hundreds of years on a unified theory to describe the world. So process designers and theorists have been dumping standards of business process flows that claimed to fits organizations from small local firms to international enterprises. So we developers work to death for generic classes, abstract implementations, standards, frameworks.
It’s just a shame to let your fellows found that you have duplicated logics or codes in your development work. Even sometimes the things in common are only bean properties of identical names. It’s just not a pretty if you don’t implements as many functions as you can with minimal number of lines of codes. The name “generic” just rocks. People creating generic things are stars.
Last but not least, money matters. The more generic a design is, the more likely it is offering functions people need. More need more money. So you boss love it. And you should love creating it.
It’s all basic instinct to love big and generic things. But should you?
Suppose you are going to design and implement a little library systems that let the staffs borrow and return books in a self help manner with a browser. Okay, let’s write the story down first…
“User can borrow and return books”.
What do you need to implement it?
- Book - The model representing a book.
- BookManager - Service class providing borrow and return operations.
- BookDAO - Data access component for saving the data to a database.
Simple enough, right? “It must be too simple. I must have missed something.” You said to yourself.
Oh… oh…. but wait. People borrow “things”. There are many assets in your company are borrowed and returned frequently and yet your company still don’t have a system to manage it. Notebooks, VCR, projectors, salary (Yes, you can borrow your next month’s salary ><b). Genius, perhaps you can expand it a little bit to make the design capable of handling these things as well, potentially. Let’s do it.
- Resource - Interface decorating any “things” that are allowed to be borrowed and returned.
- AbstractResource implements AbstractBorrowableResource - A default yet abstract implementation.
- Book extends AbstractResource - Implementation for book.
- ResourceManager - Interface defining a service that handles operations related to borrows and returns.
- AbstractResourceManager implements AbstractResource - Implementation of service for others to extend and implement the real stuff.
- BookManager extends AbstractResourceManager - Implementation for book service.
- ResourceDAO - Interface. You know what it is. I am lazy.
- AbstractResourceDAO implements ResourceDAO - I guess you know.
- BookDAO extends AbstractResourceDAO – Cough~ Cough.
Looks great now. You now got an extensible hierarchy, interface driven. What else do you need? Yay~ Yay. Modules.
It is generally good to separate the API and actual implementations so that when people code in parallel without caring if you are in a fighting hard to get your implementations compiled. With API extracted the API itself might be reused in other projects as well, though you can’t think of what sort of projects would like to include it at the moment. Yes, it is generally good. So you do it in 2 modules: resource-api, resource-code. Out of luck your favorite IDE you-know-which does not support well multi modules development so you spend quite a time figuring out the right way to do it. To meet the deadline you work sleeplessly for days. Finally God blessed you this brave code monkey you got all the things sticked together.
Your manager shows up as you get out of Alice’s rabbit hole, a week behind schedule. He is so highly educated he decided to not to comment on your smelling body. You showed him your work. Nothing happens… Oh I mean bugs. A week later the system is put into production. Staff can now borrow and return books on their own. Managers no longer need to worry about where do their most valuable books go. A year after, people are still borrowing and returning books. You, on the other side, still live as a sleepless code monkey. No other project cares about the API library except the system itself.
It won’t be fun at all if I tell you what’s behind the story. I might have amplified part of it a bit. But most of it are borrowed from real stories. Oh, borrow.
You should love them. But be pragmatic…
You should love big and generic things & ideas. It’s basic instinct. You can’t control yourself not to love them. There are, however, reasons why you should do more small solutions rather than a few big solutions when you layout your development.
- Real value comes from real things
Real values of thing only show when the thing becomes real. This is specially true when it comes to user usability. Unless you know well now to generalize an implementation as you might have do it before, it is likely to be a waste of effort to make things generalized before users told the value. You better save your effort on other more practical and valuable targets, or to take a rest. - User don’t care!
User don’t care if you are providing generic features or implementations. They just want their job done. They borrow books. They borrow equipments. They won’t care if the things they borrow are under the name of “resource”. I’ve seen many times applications implemented a so generic way that attempt to do almost everything related to its target scope end up getting users lost in configuration hell and navigation maze. It’s often no single user knows the whole application. If user have need to do common things in a more effective way, they will let you know when they use it. Make it work first, then the real patterns show up when your users get their hands on it. - More rolls more wins
This is what one of my favorite book The Max Strategy: How A Buisnessman Got Stuck At An Airport suggests. Do more small solutions. Join and refactor only when need. By giving more chances the market and users accesses your new ideas, you make more chances of getting success. - Diversify risk
Unless God hates you, or Murphy blesses you, you are less likely to get all the small solutions go wrong. One big solution, go wrong often. Even it has the same chance of going wrong as that of small solutions on average, big solutions still bears bigger risk. As big solution takes more time to develop, you know the result late. That said, as the deadline is close, you got little room to fix it or place an alternative in time. - Duplicates != Evils
Duplicated codes or logics are not evils. They are when first, you never have the idea in mind to refactor it whenever you can spare time or need to do it. Second, they are removed through generalization in an unusable way. That said, they are generalized only because you want to generalize them. Not for value or need. Things look common are not necessary duplicates of each other. Take a real close look. They might just looks similar to each other. - Geek you can always refactor
As long as you follows common good programming practices, say properly organize your packages and encapsulate logics, test driven, you can always refactor to capture the commons. - Lesson from the mother nature
Look at your body. If you ever considered it as one of the finest creation from God, then learn from it. It evolves over time from very simple and small structures to an integrated and multi-function structure today.
Genius-free development
I admit that there are genius in this world who can create master pieces with few iterations. When I was in college taking an A.I course, I worked with a guy to build an expert system for identifying whales as an assignment. He took the job of engine development while I took the front-end part. For days this guy sit in front of the computer, rarely types but spent most of the time meditating while I kept muddling through tons of compilation errors and bugs by his side. Finally he compiled his codes and run the engine. Almost no error pop during the process except a few minor typo. It just runs, smooth and quick. The guy is a real genius.
I am not genius. I believe 99.99% of us are not either. But we can still build big successful solutions. Starts small. Move frequent. Be iterative. It might take more steps then genius do. But for the rest of us, it could be perhaps the shortest path we could take towards success.
Leave a Comment so far
Leave a comment
