Almighty golden rules of computer development
My views about software are sometime different than what most programmers seems to harbour. I recollected some of my belief about software development that are in direct shock with some widely-accepted thoughts.
#1 Rule : There are no rules.
If you need to do an ugly hack or redesign something, by all mean do it, as long as you are conscious about the long-term effects, portability and stability issues that comes with it, it is your choice. Try not to be the rigid programmer that only sees one way to be right. Personally I use hacks and tricks for the touch-ups - but not in building blocks. In other words, the core is rock-solid, and to achieve features I allow myself seldom incongruities on the outer layers if it adds value in flexibility or ease of development for developers.
It is better to have a fully working software that meets client needs than a half-working piece of art that respects theoretical guidelines. An interesting post on C++ FAQ : http://www.parashift.com/c++-faq/use-evil-things-sometimes.html
#2 Rule : Time is elastic
If someone tells you to write a project in 2 weeks, you will write it in 2 weeks. If someone tells you to finish by end of July, you will finish by end of July. The features and precisions will vary, but in the last 10 years I have worked this rule always applied to me. On the last project they put me on to, we had 2 months left of time, and 4 month worth of features to code, we finished in time ! But the stake was high, if we didn't finish on time, our company would not get paid
#3 Troubleshooting does not necessarily require intelligence
Yes that is right ! Most people get afraid in front of a problem. I guess we believing we will never pierce the logic barrier proposed by the problem at hand. We don't need to. We just need to get back to a working scenario, even if far from the real buggy implementation, and then slowly bring the two scenarios together by small iterations. At some point the working scenario will break and you will have found what causes the problem. The hard part is then just to have the audacity of choosing a working scenario.
#4 Rule : If you are on the bleeding edge, you bleed.
There is a huge gab between developers and management. Developers could like to use bleeding edge libraries and work in a cool and fresh environment. On the other hand management cares about user-features, stability and predictability in time estimations. It always the same story, the first year or two of a large project are intense. For example I prefer to let others break their neck with new libraries, and after 3-4 years when it is ultra-stable and well-known, I use it. You get a more stable framework faster to build to release-ready, than use a new flashy framework X implemented by super-star coder A mentioned in popular tech magazine XYZ.
#5 Tip : Break down the problem into a simpler achievement
This is the beginner's mistake. Undertaking something too big. Not committing for days. Going for days without compilation, or simply being frightened with the task at hand. This is for beginners so most already know this or another variation of the idea. Break down the problem into a simpler achievements. This might sounds like project planning. However it is related to coding as well. So I'm talking about problem-solving and coding. When you face a too-big challenge, you want to know as soon as possible that you are making progress and going into a feasible direction. If you can break a challenging task into two stages, you can help yourself succeed. For example if you try to develop a distributed network communicating between nodes with jsonp, before trying to make a command work across servers, try to make it work locally even though the final product doesn't do that. Also, the coding technique of using small unit-tests is also a method that goes into this direction - however I have an opinion on that too...
#6 Rule : Well placed unit tests are time-savers
I'm sometimes disgusted about the time spent on useless unit tests by developers. I truly believe that core functions should be harnessed to unit-tests. Functions that do data-manipulation. Unit tests for corner-cases, or extreme values. For final user test-cases (front-end), most of the time it is redundant, and in the long-term loss of time. The front-end functionalities can be tested using automation. In this case I'm suggesting to do front-end automated testing and not code-level unit-tests on code near the front-end. So in short, my view on unit-tests are : for lower-level core functions and corner cases : yes. For front-end testing : do not use unit tests, use automated user-interface tests: it is more reliable as it will test more stuff at once. Keep in mind that front-end changes more often than core-functionnalities. Sometime front-end unit tests are a lost of time as you pass more time fixing unit tests than real bugs.