Three Lessons in Software Development (and more)

12 years in software industry have been quite eventful. Requirements Management, Design, Testing, Reviews, Methodologies, New Tools, Customer Feedbacks, Escalations, Expectations Management – it has been a roller coaster ride for me. I have thoroughly enjoyed it while learning some of the very important lessons.

Just when I was thinking of summarizing some of my key lessons in software development, I came across this wonderful series “Lessons in Software” over at Shaping Software Blog. Use following links to read all three parts: (Highly recommended reading)

• Lessons in Software from Alok Shrivastava
• Lessons in Software from James Waletzky
• Lessons in Software from Mike de Libero

I loved all of them but following three lessons resonated very well with what I strongly believe:

• Coding is Easy, Humans are Tough (from Mike de Libero)
  80% of software development is a people sport. Technical knowledge is still very important, but not only enough. Programmers/Developers today are expected to know how to deal with other human beings (clients, managers and peers) and keep their goals larger than their egos. It pains to see people on a project teams operating from their egos. Most importantly, even clients need to understand the “human” aspect of software development. I have seen clients who treat people like Robots.

  Mike says:

Don’t get me wrong, there are some hard problems in coding but they are not as hard as figuring out what our fellow beings want out of a piece of software.  Humans tend to be fickle and contradict what they say.  On top of that it is very hard to communicate clearly and a barrier exists between “geek-speak” and normal vocabulary.  It becomes extremely difficult to figure out what users are asking for.

• Learn Software Development, Not Coding (again from Mike)
  This has been one of the most important lessons I have learnt personally. Software development is an art much larger than just having ability to code. It is about comprehension (of requirements), design, execution (coding), communication and overall expectations management. Coding is one small part of overall game, so don’t underplay yourself by simply remaining a coder. Remember: Knowledge of Coding + Processes + Business Understanding = Great Software Developer

  Mike mentions:

Personally I make a distinction between coding and actual software development.  I think there are far too many people who focus on just the coding portion and not the bigger picture.  Many people can write code but it seems fewer people can design a system, test a system, write the code, document the architecture, talk to users to figure out requirements, create semi-accurate estimates, help other team members and when designing a user interface know the basics of user interaction.  There are things all developers should know about coding as well but I feel improving your coding chops is pretty easy and is done as you develop software.  Learning and improving in regards to software development is not necessary for one to hold done a job as a programmer.

• Unit Testing is #1 Quality Practice (from James Waletzky)
  Code isn’t complete till it “works”. Good unit testing is a primary responsibility of a developer – not something that is shunned when schedules are tight. I have heard people arguing that they did not do unit testing because of a tight schedule. This only means testing team will take more time in uncovering your unit level defects. No time saved effectively. Great developers know that unit testing is extremely crucial activity which only helps them improve quality of their output.

  James says:

I often get asked the following question: if I could change one thing about software development to encourage improved early-development cycle quality, what would it be? Easy – improved unit testing. Historically at many companies, developers would write the code, run the “happy path” through the debugger, and throw the code over the wall to the test team for validation. Quality would be “tested in”. On more recent teams we have been doing much more unit testing  using code coverage as a feedback mechanism and quality has risen substantially. Additionally, unit tests give you the confidence to refactor your code at any moment in time leading to cleaner designs and more maintainable code. The icing on the cake is having the tests run as part of a daily build, so you always have quick feedback as to whether functionality is broken. The disadvantages are that unit tests take time to write and you add 50%+ more code to your product, but the investment is worth it.

I know this post has gone longer – but I could have still gone on and on. I strongly recommend that every Project Manager, Technical Leads, Process Experts and Software Developers should read these three very informative articles. Having done that, they should implement these.

At the end of the day, it all boils down to execution. Knowing is great – but executing what you know systematically is even greater.

What lessons have you learnt about Software Development?