Sunday, June 29, 2014
By the way, Antoine de Saint-Expury was not only the author of "The Little Prince", but also a renowned aviator and aviation designer. Given the state of aviation at the time he was flying, less was definitely more.
So why is this important for Software Development as well? Basically it encapsulates and summarizes multiple themes we use; DRY, Minimally Viable Product, Re-factor, etc.
I've seen many projects get in trouble and even fail because this simple maxim was ignored; building more than the customer asked for; building stuff the customer asked for, but didn't really need; not planning out code libraries in advance; not taking advantage of abstract base classes and/or generics.
It's difficult to follow this maxim. It requires some careful planning up front, and some vicious code refactoring AS YOU'RE GOING ALONG. You must be re-factoring, and following DRY principles every single day. Why is this important?
Every single line of code you write is a potential bug. The fewer lines of code, the fewer potential bugs.
The fewer lines of code, presumably, the fewer unit-tests have to be written (which are subject to having their own bugs).
The fewer lines of code, the easier it is for someone else (or you six months later) to read and understand the code.
The fewer lines of code, the easier it will be to extend the application. When you think you are done coding, ask yourself "How much more code can I remove?"
Finally, I mentioned above that this quote applies to more than just software development. Another favorite quote is one I use with #2 child when #2 has a writing project in school. The quote comes from a famous author, whose name escapes me at the moment. It's an apology for a long letter written to a friend. "I would have written a shorter letter, but I didn't have enough time." In other words, I didn't have enough time to remove all the unnecessary words.
Edit, slash, cut & burn; your code will be better for it...
Friday, June 20, 2014
Granted, I’m a curmudgeon, and take umbrage at things that other’s might easily overlook or forgive. But making simple spelling mistakes on an email blast that represents your company to the world does not strike me as a way to make a great impression. I received this email today:
I’m sure whatever tool was used to create the original email had some spell check capability.
Is this company too proud to use a spell checker? If they’re not willing, or not smart enough, to use spell checking on a public document, what confidence do you have they will be careful with the work they do for you?
Thursday, June 12, 2014
This is a question that comes up a lot during planning meetings for Agile projects. Each product, story, feature, etc. ought to have a definition of when it’s “done”.
Recently, we’ve seen an excellent example in our industry. The end of XP…
It’s done. No more work will be done on it. No more support efforts will be provided. It’s dead. Finito. Walked the plank. Entered the great unknown from which none ever returns.
This is actually very useful for us in planning. Ask yourself, when the issue of “done” arises: at what point will I stop working on this.