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.

I was invited for a guest lecture to the computer science students of the “Hindustan Institutions“, Coimbatore. The head of computer science department and my friend Rangaraj had been discussing for quite some time about collaborating education institutions with the industry, for the students and teachers to get some perspective of current trends.

The problem that exists today in India is the wide gap in what is taught in colleges (only with respect to computer science related courses) versus what is expected in the software industry. On one side is the outdated syllabus that majority of the subjects are either not being used in the industry or outdated. On the other side is the lack of training, grooming and guiding students on the expected soft skills when they enter the industry. While we could keep complaining about the education system and point finger at the Government, it is not going to solve this problem. We cannot blame the teachers in the colleges as well, because they may not be exposed or aware of the industry needs. The ideal solution is the industry start collaborating with the education institutions. All of us have gone through our system and faced the reality of expectation mismatch when a fresh pass out from college joins a software company.

So my friend and I decided, we would kick start this process and start off an awareness session. So I prepared a mindmap on points that students should focus on the technical side as well as from the soft skills side and work towards those points. I also covered some points on preparing for interviews.

In fact this session is an awareness program not just for the students but also for the lecturers. These points are only triggering points and are not solutions. This presentation is a starting point, more of such sort has to happen focusing deeply on each of the points I was mentioning and definitely this industry can help the education institutions to guide and build a better tomorrow for the students as well as the industry.

Click on the photo for a larger image of the mind map. Have a look at some photos taken during the lecture in Flickr.

This post is part of “Foundations” series of posts.

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?

Happy weekend.

In software architecture, defining and implementing Non Functional Requirements (NFR) impact the degree of satisfaction of the stakeholders of the system. Non functional requirements determine the Quality of Service (QoS) of the system. QoS has a huge impact on the quality of the system in terms of how well the system is able to satisfy the behavior (functional requirements) of the system. To achieve the QoS, the implementation of the NFR depends on how SMART they have been defined, where SMART refers to, Specific, Measurable, Attainable, Realizable and Traceable requirements.

QoS is not only applicable for architecture but as an individual for all of us. It determines how much of quality of service we provide in what we do. Hence working harder is not enough but working SMART’er is very important. Let’s define SMART in terms of an individual’s quality of service.

• Specific - One should know what are his/her roles and responsibilities clearly. Specific also refers to Scope here. The more you deviate from the scope of work, the more confused you will be and will lead to chaos in planning, prioritizing and executing. Simply put you don’t want to be “Jack of all trades, master of none.”
• Measurable - Completing a work is one aspect. The other aspect is how effectively the work has been completed. That would require defining a quantifiable objective that can be measured in what has been done. This leads to benchmarking yourself and determining where you stand in terms of effectiveness in what you do.
• Attainable - Defining a goal for the task you are performing and making sure that it is achievable is important to confidently proceeding in performing the task. Clearly differentiate between what is possible versus what is not possible. Time, Money and Resources are the three quadrants that play a crucial role in identifying what is possible versus what is not.
• Realizable - This defines what is expected out of what you are doing. Essentially this is the end result of what is being done and what the stakeholders expect out of your work. Remember there cannot be any task or work without stakeholders. Even if you are working on something that you are going to use, you are still a stakeholder and would have expectations. I am sure you would want something best for yourself. So if the stakeholder is someone else they too would want the best outcome.
• Traceable - There is a lesson to learn in everything we do. These lessons build the experience and expertise factor. Tracing back what is done, what went right and what went wrong will result in a collection of what to do’s and what not do’s. Remember making a mistake is OK but repeating it is not OK. A mental imprint of events that affect our emotional mind is there with us throughout our life. But that may not be always the case in the tasks that we do in our career. Hence keeping a document of lessons learnt might be very handy as you move ahead. That could also become a reference for others to use without wasting time going through the same mistakes.

There are some professions where physical effort is more needed than the mental effort. These professions could be more mechanical in nature. In such environments working harder may be sufficient. It is not the same case in software industry where mental effort plays a major role than (almost no) physical effort. While working harder is important, it is just not enough to be successful and to grow. What is needed is to work SMART. So don’t just work hard but work SMART.

This post is part of “Foundations” series of posts.

“Life’s not a spectator sport. If watchin’ is all you’re gonna do… then you’re gonna watch your life go by without ya.”

That was a dialogue by one of the Gorgoyle’s in the movie “The Hunchback of Notre Dame“, a Disney classic movie. Everyone is caught up with work, personal work, career work. How often have you said “Time flies by”? How often have you answered the question “What are those initiatives taken by me to go beyond what I am supposed to do?”. If you are unable to list any to that question convincingly, then probably the above dialogue is for you. Start thinking what is that something you can do on your own more than what you are currently doing. It could be as simple as learning something new, creating a tool that would automate some manual work in your organization etc. These are small things that provide you that competitive edge over anyone else who just stick to what has been assigned to them. Think about this. If you are applying for a job, what are those significant value adds you have that you can talk about beyond your experience and projects. In this fast paced world, what the industry needs are people who can take the driving seat than just take the ride. If you are always a spectator, then you will see your life go by without you very soon.

PS :- This post is part of the Foundations series.

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.

1. It is all behavior - Business and Technology should refer to the same system in the same way
2. Where is the business value - Any system should have an identified, verifiable value to the business
3. 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.

If you ask me, if I love documentation, I would join the majority club, a big NO. But something I am fascinated to do is typing real fast. I would say that I have significantly gained time because of it. If you ask me how, my answer would be the fraction of second I save over a period of time that has made a difference. Maybe hard to realize but I value it. Typing is less of a pain for me for tasks like sending mails, writing a post on the blog, coding when I know what I am doing and the list can go on. I am a keyboard man rather than a mouse man. I love working on my laptop, using my keyboard most of the time (after some thinking I realized I use mouse when I only need some action dependent on a right click). That’s another reason I love to work on a shell prompt or DOS prompt as much rather than on a GUI environment.

I am thankful to my mom, for without her I would not have learnt typewriting. After I finished my schooling my mom wanted me to learn typewriting. I asked her why. She told me that she wanted to do it when she was young but couldn’t do it, and so she wanted me to do it. When I completed the senior grade typing I never thought it would help me until recently when I started observing people more closely, particularly people involved in Software industry.

Those who do not know typewriting, key in looking at the keyboard rather than looking at the monitor. Because they are not used to the keyboard layout and hand-eye coordination is needed to press each and every letter. This definitely causes considerable time lag. The next disadvantage is if one looks at the keyboard and types one has to go back and forth looking into the monitor and keyboard to see if there were any mistakes and correct them. An addendum to this problem is sometimes people don’t realize that due to some reason the focus would have gone to another application which is not expecting an input from the user through keyboard. And the person doesn’t realize until he/she looks into the monitor. You might ask how does it matter but the saying “Small drops of water make an ocean” is what I could think of. The fraction of time I save makes an overall difference. For example typing mails is the quickest thing that I could finish off, provided I know what I have to write.

If you want to leverage speed of typing and learn typewriting, you could do it online. Just Google and you will get lot of sites that teach typewriting online. The first basic rule when learning is to never look at the keyboard and type. It is OK you will make mistakes initially but slowly your hands know where the keys are and you will realize how easy it is to see the monitor and keep typing. By the way if you want to test your typing speed click this link “See how fast you can type“.

Happy Weekend!

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?