Programming, Music and other fun stuff: Strategies that produce Great Software

Strategies that produce Great Software

based on the Apple WWDC 2014 Video by: Ken Kocienda

When adopting 3rd party controls, try to get a demo as soon as possible. The ease in adoption of the framework will tell how likely it is to be useful in your project. Rather than striving for code-complete perfect implementation, make a minimal viable product to demo and throw stones at, so that an understanding of feasibility can be made, and the size of the gap to be bridged. Know a good idea when you see it by testing the prototype.

Don't try to solve every single problem right away. When adopting libraries, you might want to only use the parts you are going to use. So pull out the parts you want, and only bring those in, rather than using the whole project which you will not use all of. This process can take time, however, because likely the creator of the Third Party library did not intend this. Have achievable goals. For example, when Apple was integrating KHTML to build Safari WebKit for the first time, after integrating everything, only a "Black Obelisk" would show on the screen (black rectangle). You won't be able to address every point in a huge problem right away. Just try to get something drawing on the screen.

Ask for help if you don't feel like you're making sufficient progress. Are you trying to use an API that is too low level for what you are trying to do? If that's the case, consider building your own API which does exactly what you are trying to accomplish. When framing the requirement from a higher abstraction, you will get the benefit of having the code structure organized. So you may still need to use the low level APIs to get there, but at-least the higher Level API design helps you organize the code with clarity. In other words if a low level API doesn't serve your purpose, build a higher level API abstraction around it, in order to simplify the interaction with the calling code. (Facade or Bridge). Get input from smart colleagues if you are stuck. They will always have a different perspective.

It's great to be able to use something that people are aware of, so you don't have to train them. Everyone is familiar with the QWERTY keyboard. Work should explain itself (by convention).

Choose the simplest idea which might work. For example, when you type on a keyboard with Auto-correct, if you make the dictionary look up very fast (O logN), it might make sense to look up every combination of neighbouring letters next to the keys you pressed, and actually look up all those permutation - for any word length. (Every word on every keystroke)

Only show your best work. Test out all the ideas, pick the best idea and really test it out. When the time to make the decision comes, you will have all the information to make the best decision. When you have gone through all this effort, you will have your best work distilled into a Demo which will succeed.

Can we go faster than the iterative cycle of: Demo to Designer, Make Changes, Demo Again etc... Instead we can have "Tunable Values" to reduce iteration time. This way the designer can make changes on the fly, such as "Make something 2% darker". Every single value can be polished to perfection by the designer now. The designer tunes it until he is completely satisfied, then you take the produced slider values and commit that to the code base. This eliminates all the iterations which would have been needed, if tuning was not in place. Therefore: "Iterating quicker leads to better work".

Be kind to people, but be honest about their work. Never raise your voice. The people are most likely trying very hard to produce good work, but you still have to be honest and up-front about the quality of the work, and let them know that. They will also not take your feedback personally. You need to separate yourself from your work emotionally. If your solution is viewed as that of poor quality, you shouldn't take it personally. It's just an opportunity for improvement.

You are never "done" in Technology. It moves fast, and you need to keep up. Try to do the best possible job at any given time. Don't dwell too long on something that is pretty good, but rather move on to the next step. Often times you will have to "Rewrite" your solution completely, while working on it. This is because of valuable lessons you could have learned during development, or input from colleagues. This is not a bad thing, rather: an opportunity for improvement and learning. Technical humility is a great trait to have in this field.