Complex software projects like NGRPulse, NGRERP, etc, have a long development cycle. You are passionate about technology and someone has to nudge you to start the project. Then you start understanding the domain a bit. The first people who you talk to will sow seeds that will go very deep and will form the genesis of the project. You start giving form to your ideas.
Then you start finding "how" to execute the ideas. You learn about software development, you learn about databases, you learn about web servers and web frameworks. Somewhere down the line, you don't like the frameworks out there so you start to write your own. After a while a prototype is emerges. You are forced to implement it immediately because the legacy software has crashed and the original developer has left the country. You work on your prototype, fixing bugs under pressure and veiled threats from users.
Then you think its time to start a company, but you don't know about business, so you rope in a partner. You do sales, pitches, projects, code, make website, document, recruit. You don't really understand the industry and the market so you struggle. Customers don't close deals, those who have don't pay up. You keep doing pitches and waste time. You keep changing your business strategy. You realize your first ideas were very bad. Losses start piling up. Things start falling apart. Your team loses faith in you. Servers crash. Tears flow. You are generally in a mess.
You hang on either by default or fate, things start improving a bit. You start understanding things better. The code improves. The market strategy gets clearer. The product progresses and matures. The users grow a bit. You have much deeper domain knowledge. But the product still sucks. The technology and design world moves even faster. You still have a lot of catching up to do.
What is constant in all this is change. Users change, strategies change, technologies change, designs change, domains change, expectations change. What is clear is that you start someplace and you quickly keep moving or are forced to move. The real challenge is to be ready to constantly change and renew.
In my days of studying Electronic Engineering (no, I am not formally trained in software), I learnt of this concept of "Design for Manufacturing". What it meant that a design should be easy to manufacture. All parts must be of material and sizes must be standard, body shapes must be easy to cast / die, the parts must be easy to assemble etc. This kind of thinking does wonders for profitability and quality. It does not take a lot of brains to understand why.
The analogy for this in software engineering is "Design-for-Change". A software is more like a narrative than a product. Your features are characters and your usability is the pace of the plot. If the narrative is short (blog post), you can rewrite it easily. When you start you probably have a lot of ideas in your mind about what you have to write. But a software product is like a really long narrative and you can rewrite it only part by part.
Principles of Design-for-Change in software are also very similar to Design-for-Manufacturing:
"DRY" or don't-repeat-yourself: This is really hard because many times patterns start forming much earlier than you realize. Say if you want to change the way a button behaves and there are many other such buttons that you will have to change individually, then tough luck. You are stuck with your current design.
Use standard libraries: Libraries keep updating themselves and also have communities to support them. With the introduction of Twitter Bootstrap, JQuery + Bootstrap is a killer combo for web development.
Write clear code with consistent naming: It should be intuitive to anticipate where this code might be specially if you have large number of code files.
Learn from your mistakes: Take time out to think about why something went wrong and what can you do to avoid it. Many times we just keep moving from issue to issue without taking a step back to realize why things happen.
Automated testing: This would have been great for us but we did not start out test-driven and right now we have so much "wiring" that testing the basic components does not make much sense as the faults are mostly in the wiring.
In the end there is nothing to beat experience. You may get lucky if your product comes out good for the first time. Change is also a test because you are constantly questioning your own thinking. People who look up to you are also confused, but when you know that what you have is not the best, change is the only option. And this only thing that can make things a bit easier is if your product is designed to be in a constant state of change.
Comments