Tales of software development
This is my humble effort of summarizing hours upon hours of endless discussions on software development.
Read. Learn from those before you. If you will ever be involved in a software project I assure you that one of the following books will come in handy:
Frederick P. Brooks, The Mythical Man-Month (2nd edition), Addison-Wesley 1995
Steve McConell: Code Complete 2, Microsoft Press, 2004
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series), Addison-Wesley 1995
A Hunt, D. Thomas: The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley, 1994
And stop and read now Peter Norvig - Teach Yourself Programming in Ten Years : http://norvig.com/21-days.html
Don’t underestimate the experience of others. It takes at least 10,000 hours of practice to master any craft. Don’t think those hours of practice mastering this craft can ever be replaced. Respect those dedicated enough to put in those numbers.
1. Software development is a craft
Remember, the purpose of software development is actual software. Software development is not for everyone. If you think developers are interchangeable you are sorely mistaken. It’s like writing a novel and changing the writer in the middle of a sentence. It doesn’t work or if it works then you are writing a very, very bad novel.
There is a reason why Linust Torvals is still answering mailing lists for Linux kernel (http://www.wired.com/wiredenterprise/2013/07/linus-torvalds-right-to-offend/), why Anders Hejlsberg proved successful twice (with Delphi and C#) in a field where almost everyone else fails.
Practice. Code. Even if you are not actively coding do it sometimes in your own free time. Build products and when possible, use them. Never underestimate the power of eating your own dog food. http://en.wikipedia.org/wiki/Eating_your_own_dog_food
Lead by example. The best developers/architects/designers/product managers output their work into successful products. You need all of them to build great products. Seek those reminiscing about great products. Do that yourself and document problems and solutions; never remember excuses. In the end, they are meaningless.
Trust the people you are working with. Assume that they are doing their best and don’t second guess their expertise. Let them have their choice of tools, algorithms, methodology, programing languages or databases. Many of them are almost religious about their choice.
"Nine women can't make a baby in one month". - Fred Brooks.
Never use lines of code as a metric as you would never judge a book by it’s length. Always assign weights to functionality and bugs, remember to quantify the effort involved both for development and testing.
Remember that an estimate is not a promise and don’t think that throwing another developer (or resource) will complete the work faster. It almost never works. Coding/programing/development is all about the context, so always plan accordingly, allocate time for them to understand the business problem, the architecture, the constraints. Let people work on one task at a time, respect the concentration of a programmer submersed into a project and don’t break it, further estimates/reports/chit-chat are not more important than actual work. Context switching for humans comes with a great time penalty. So does CPU task switching but that is another topic. Any meeting, progress report, estimate is not as important as actual code.
The one and only purpose of testing is to check that the software runs as expected. Testing should be easy to re-run, regardless if it is unit testing, integration testing and system testing. Keep logs of tests performed over time but don’t overdo it with proofs of tests. Don’t waste anyone's time with screen-shots and reports. No one is paying for excuses.
Keep in mind that acceptance testing will trigger user feedback and new features. Be aware, this does mean failed testing, future development is to be expected on every software project but focus on delivering what you have promised in the beginning.
4. Customer/ user feedback
The customer/user has problems and needs. Listen very carefully and focus on the problem, not the solution he is suggesting. Most of them will state solutions to their problems, not the actual problem. Assume the role of a doctor, listen to the problem, the patient knows exactly what is bothering him but don’t prescribe a remedy based on patient recommendation. Self medicating is not advisable.
Build mock-ups, preferably live mock-ups, include real data, make the extra effort of A/B testing and sometimes invest in mock-up features that will never make it to production. Get feedback and be flexible in the beginning in accommodating change, but rigid in the later stages.
dededos
blakekathryn
areudirty
janainaart
snowghoul
baratheonpilled
kaledo-art
vaporwave