Copy and paste is a design error.
-David Parnas
Once a developer groks this quote, he/she has already achieved another level of understanding software development. :D
Form is emptiness, emptiness is form.
Copy and paste is a design error.
-David Parnas
Once a developer groks this quote, he/she has already achieved another level of understanding software development. :D
While I was fixing my Google Reader feed for BusinessWorld‘s IT Matters site (they changed from http://www.itmatters.com.ph/RSS/itmatters.rss to http://www.bworldonline.com/RSS/itmatters.rss), one article caught my eye:
My first reaction was, “No sh*t, Sherlock!” After reading the article and finding out that it’s not talking about software engineering practices (which I am sure isn’t being practiced by many local software houses) but the low adoption rates of best practices in Auditing and Risk Management in IT departments, my reaction was still “No sh*t, Sherlock!”. I mean, if you’re dealing with foreign clients and yet you’re not familiar with those processes then you have a big problem on your hands. Either that or you know a good place with steak and strippers.
Since we’re at the topic of Best Practices, I might as well cover it in this post.
Spent the day tweaking my SweetCron based frontpage lifestream (nakikiuso as usual :P ). The theme’s currently a mix between Tarot and CCG frame templates. If all goes well, I should be able to tweak that to use more xxxHolic and Persona motifs.
It’s already 10 PM so I’ll keep this short.
—
If you’re a Computer Science student, you should at least learn the following before graduating regardless if it’s in your college’s curriculum or not:
Trust me on this.
“Not Invented Here” (NIH) is another fundamental concept in that one must understand when entering software development.
There are a lot of issues and concepts related to NIH (as seen in the WikiWikiWeb page) so for this post, I will only cover the basic concepts in this post.
Whenever possible, steal code.
– Tom Duff, Bell Labs, quoted in Programming Pearls
“Not Invented Here” (NIH) is another fundamental concept in that one must understand when entering software development. NIH describes the tendency of an individual or organization to refuse using an available solution (say, open source software) just because it was not invented by them (hence, not invented here).
There are a lot of issues and concepts related to NIH (as seen in the WikiWikiWeb page) so I’ll only cover the basic concepts in this post.
—
The first time I read about NIH is in Alistair Cockburn’s Agile Software Development: The Cooperative Game. There is something about Cockburn’s (pronounced Co-burn -___-) approach to NIH that separates it from the other perceptions of NIH. Unlike those who add “syndrome” at the end of NIH, he treats NIH not as a disease but as a cultural imperative. That is, people and organizations practice NIH because their culture trained them to do so from an early age.
From earliest school days, students are instructed not to copy other people’s work, to not help each other, and to be as original as possible in all but rote memory acts. They are given positive marks for originality and punished for using other people’s solutions. (Recently, a fourth grade teacher told her students not to call each other to discuss homework problems—not even to ask for which problems to do!).
Through the university level, assignments are designed to produce grades for individual work, not for teamwork. This reaches a culmination in the Ph.D. dissertation, where originality is a core requirement.
Somewhere in these years of schooling, some people join the profession of “programmer,” a person whose job is to program and who advances in the profession by writing harder and more uniquely original programs.
Under these circumstances, it is hardly surprising that the people internalize the Invent-Here-Now Imperative.
If you’re unfamiliar with software development, you might ask:
So what’s the problem with striving for originality?
For software engineers, the answer is simple:
It’s usually a waste of time and resources.
Modern software development is different from school. When an English teacher asks you to write a short story and you copy one off the net, you’re a plagiarist. Depending on your educational institution, you could be expelled for that act.
On the other hand, if a client wants you to set up a CMS for his company and you use Joomla, Drupal, or whatever open source CMS for it, you’re a pragmatist: you just saved thousands of hours of development and testing when compared to writing one from scratch.
—
That said, I’d like to point out two things related to NIH:
First off, it does not mean that “code reuse is always good” and “NIH is always bad”. In fact, Cockburn’s reason why he mentioned NIH in the book is not to condemn it outright, but to show us the importance of researching over inventing.
This means that, when faced with a programming task, a software developer must first research for the simplest solution available. It may be in the form of a built in function or class in her framework, or it may even be someone else’s code. A developer would only code everything from scratch is if the task is trivial and disposable, or if the effort of researching (or modifying, if a third party module is used) in both the short and long term is larger than coding from scratch.
—
The other implication of NIH is that it exposes the fact that traditional teaching methods (i.e. those used in computer science courses in college) is not conducive to producing quality software developers needed by the industry.
I would agree that computer science should program their own MPs instead of copying from their classmates (speaking as the-guy-who-never-copied-code-from-anyone, I personally found this behavior insulting back in college). But the problem here is that throughout a computer science student’s life in college, the student is taught to value originality as they are valued in other courses.
By adopting an NIH culture, computer classes continually promote values that are considered detrimental in software teams: independence instead of teamwork, pride over one’s own work instead of open mindedness towards other solutions, writing throwaway code instead of writing maintainable code, etc.
Now you have an idea of what I have to deal with when I was a trainer for my previous company. :P
As much as I’d like to go back to talking about management and software engineering (to scare away the people who stumbled upon my site because of the incoming links), DDB “damage control” people decided to submit their entire freaking FAQ as comments to two of my posts.
Now that gives me a good reason to continue talking about their site while bridging the gap between this issue and software engineering. :D
—
Practically the main reason why people are skeptical about the Ako Mismo website is its lack of usability.
Now, when we talk about usability, the first reference book that would come into mind for many web developers is Steve Krug’s Don’t Make Me Think. The book covers the main issues on usability faced by websites and does this by being clear and non-technical and by using pretty pictures. In other words, the book’s a perfect for people interested in improving their site’s usability but would be intimidated by Jakob Nielsen’s useit.com or Edward Tufte’s books.
As with most decent software engineering or web design books, you probably won’t find this book in local stores. A former colleague told me that Fully Booked carries this book sometimes though I haven’t verified it myself. You could try making a special order from local bookstores for it but that would lead us back to the book blockade thingy. =/
Fortunately, there are free chapters of the book available on the net. One of those chapters is available in the Adobe Design Center: Usability as common courtesy.
Usability is about building clarity into Web sites: making sure that users can understand what it is they’re looking at — and how to use it — without undue effort. Is it clear to people? Do they “get it”?
But there’s another important component to web usability: doing the right thing — being considerate of the user. Besides “Is my site clear?” you also need to be asking, “Does my site behave like a mensch?”
Steve Krug starts the chapter with a story about how, after being concerned that a union strike will affect his flight, he visited an airline’s web site to find more information about the strike. Long story short, the web site did not contain any relevant information about the issue on hand and this frustrated him.
He then introduces the concept of a “reservoir of goodwill” to explain how it turned out that way. In the concept, he tells us that everyone has a reservoir of goodwill when we visit websites. When we find what we are looking for or anything similarly interesting, that reservoir fills up. Similarly, when we don’t find what we are looking for or if we see something that disgusts us, the goodwill level goes down. If for some reason that reservoir becomes empty in the course of our visit, we leave that site in disgust/frustration.
—
Back to Ako Mismo, the reservoir of goodwill easily explains why people reacted that way to the Ako Mismo site.
A lot of people entered the site with a high amount of goodwill in their reservoirs. A good number of them left when they couldn’t find any information about the dog tags.
Others’ reservoirs didn’t last that long. A part of the article actually gives the exact same reason why:
Sometimes a single mistake can empty it. For instance, just opening up a registration form with tons of fields may be enough to cause some people’s reserve to plunge instantly to zero.
—
As we can see from these examples, usability may be an often overlooked aspect of a website, but it can spell the difference between a successful sale and a lynch mob.
Unfortunately, usability is not my area of expertise so I couldn’t provide you with a comprehensive list of usability links. All I have is a link to another chapter of Don’t Make Me Think and the aforementioned useit.com site.