I was introspecting myself after reading the article “Code Quality - Why Maintenance And Risk Management Are So Important to Developers” in DZone. It is a very interesting article and the points mentioned by Reiner Eischen are very much valid. As an architect I had been a victim to many such occasions. Because if risk management is not taken care early on it hits you bad once the application is live. When that happens and you want to trace back where the problem is, you got to understand what’s happening behind the scenes. It will take a long time for you to know what’s happening if the code is not documented. Additionally to what the author says, what I have observed is, developers usually get into the mode of writing draft code pieces to check if something works or not and copy it back to the mainstream code. When that happens, consciously or unconsciously they also forget about making it clean and writing a comment to that. What developers don’t realize is that they fall victim to a not understandable code later and spend more time to add or modify something. My 2 cents.
Archive for Development
I stumbled upon the site c-jump. It is a site that markets the board game c-jump. c-jump is for children to learn the basics of programming languages such as C, C++ and Java. Interestingly not just children, even grown ups who enter the software industry would need to play this. There is this blind programming culture, wherein developers create programs not understanding the basics and using code copy paste. It is neither going to help the individual, the project nor the organization in the long run. As computer science is becoming a main stream subject in schools, acquiring programming skill is not just limited to someone studying a computer science course. It does not matter at what age one learns programming, what matters is learning the basics right. Ironically I also stumbled upon an image that has relevance to this subject. Here is the link to the image. Is programming a child’s play?
Until a couple of days, I didn’t know there was something called Behaviour-Driven Development (BDD). I realized and was quite impressed with how BDD can add value in combination with Test Driven Development (TDD). Below are the principles of BDD, copied from its home page.
- It is all behavior - Business and Technology should refer to the same system in the same way
- Where is the business value - Any system should have an identified, verifiable value to the business
- Enough is enough - Up-front analysis, design and planning all have a diminishing return
Theory is good but we understand concepts better with examples. In fact before I read about BDD at its home page I learnt how to do BDD when I read an article on “How I Learned to Love Testing” presentation, on Rails Envy. The presentation (a 30 minute quicktime movie) explains two aspects. The first aspect is why writing test code is important and how you can get to a mode from “I don’t like writing tests” to “I love testing”. The second aspect is on the BDD using the RSpec plugin for Rails. The concept is good and I really see a value, particularly the 1st principle which would help technical people start thinking and speaking in business terms throughout the development of a system. I am yet to try my hands on RSpec but based on the presentation and the links provided in the above article, I am keen on trying it soon on a project.
Here is another interesting area to look at during software development lifecycle. Once a web application goes live it is not the end. In fact its life starts getting serious once it goes live. New feature releases, updates and maintenance are part of an application’s life cycle. Unless and otherwise it is a critical application every other application would go offline during sometime of the year. During that time you do not want the users to get a “Cannot find …” error. The standard is to post a static page that says “The site is down for maintenance. We will be back shortly”. Today I was stumbling upon few sites and got into Whisher, looks like they were down for maintenance. See below the screenshot of their message. Makes a difference isn’t it?
Error and exception handling is a part and parcel of any software development. One might be handling the errors and exceptions technically well and make it easy to troubleshoot but the user experience also matters. If something doesn’t work and the user is shown an error page obviously the first reaction would be a let down feeling. But if at all something can calm the end user a bit, it would be in a way the error message is displayed. I was trying to open a document from my Gmail in Google Docs and I got an error page (snapshot below). Though I was disappointed the document was not opening, the message caught my attention and made me smile.
I recently read an interesting article and a white paper, both related to unit testing.
1. My friend Ajay Rao sent me a link titled “Real programmers don’t test“. I was wondering if it was a post against unit testing. After reading it I realized it was not so. It is a good post explaining why unit testing is not a separate task for good programmers but is part of the coding effort.
2. This whitepaper “The way of Testivus” was a reference from my friend Kanmani Raja. It is a Whitepaper that tells why unit testing is part of your job karma and not a dogma in the form of a story.
It is your karma to read them and clear your mind that unit testing is not an additional burden but part and parcel of coding effort
If you are a usability analyst then a revised version of the old saying “Too many cooks spoil the broth” fit would be “Too many clicks spoil the browse.” If you are into web application development check out how easy it is for the user to navigate to different pages of the application.
We have heard of web 2.0 with enough explanations “I think Web 2.0 is…” Even though there is no crystal clear definition that everyone agrees upon at least now we are used to this term and we hear a few jargons around it and look at a site and say “Oh yeah, a Web 2.0 site..”. Whether we agree upon those jargons as part of web 2.0 or not one must definitely admit that one of the aspects of web 2.0 being effective user participation. An increased user participation makes a site really powerful as the data needed to power the site comes for free and in abundance without any stopping. This culture has tremendously picked up and applications of all sort is coming up that is typically run by user’s data. Enterprise 2.0 is another phenomenon that pops up then and there if not as frequent as Web 2.0. Nevertheless it is matter of time this word is going to become a common term too. While I am not interested in trying to define Enterprise 2.0, what I am interested is the user participation part of Web 2.0 that is going to be prevalent in Enterprise 2.0 as well. User participation in Web 2.0 translates to employee participation in Enterprise 2.0.
The difficulty in current enterprise environment is there are too many teams that work in silo. There is no single point of means to say what’s happening as a project irrespective of how many teams under different areas of project is working on. At one point or the other these teams have to meet the dependency of each other and when they get together there are always surprises because a team doesn’t know what or how the other team is operating on and if it will satisfy the dependency needs. Rather than working as silo teams, if each and every employee is able to participate and provide update on his/her activities at a central point that gets distributed to every other member then that gives an opportunity for constant communication and collaboration. Thus a set of tools that can help make the teams collaborate and work effectively within an organization is a must. One can argue that there are already tools that do this and in fact a simple solution would be to have a common storage space where each employee could put a document containing his/her status of work. But these are formal traditional approaches that have not been very effective because usually an employee is more bothered about his/her work and tends not to see what is happening around. What we need is an informal environment and a tool that can help in an effective collaboration. Take wiki as an example, there is no predefined rule or structure to building content in a wiki. Each and every user has the same set of rights and privileges as any other user and is free to add information and link to other areas as well. Another good tool might be to have an intranet blog for each project and make each member author of the blog, so that he/she can post the updates. An RSS feed reader could be used to distribute the new content to the entire project team automatically.
Does it mean that the teams should stop creating documents and other necessary artifacts related to a project? No not at all, what employee participation helps is to capture unstructured information that gets accrued on a day to day basis. This unstructured information is an important piece that can bring to notice something going wrong at an early stage and reduce major damages later. Take for example a developer running into an issue and troubleshooting or in a situation where he/she is stuck because of dependencies. How often does other members related to it get to know about it? Give him/her a template and ask him/her to write a document, do you think it would be effectively followed? I don’t think so. But if there is an informal environment where an employee can add content free without any structure it could be effective. A developer would be more than willing to write a post on how he/she fixed an issue or explaining the situation he/she is stuck rather than creating a document.
What will make such a culture reality is when there is an attitude shift and willingness to accept such a change and work towards building it. This is easily said than done as it is not possible with one or two employees doing it but the entire organization adapting to it. It may be late but it is the near future.