Summary of the year 2011

I am continuing my series of annual retrospectives from 2010, 2008, 2007, 2006 and 2005...


There just a couple of things that probably deserve a brief mention about the year 2011:

• I've been given recently a new role in the company I work for - to lead the development of one of our products. It's an interesting challenge. I am a bit reluctant to get overly specialized, since till now I've been contributed in a much broader scope, but there are obviously benefits of thinking and working in a more narrow context.
• In the last month or so, I've been active in improving the company development process - mainly by assessing our current tools and practices and searching/evaluating others. It seems that we will soon transition to a better version control system (PlasticSCM). Also we might adopt various other tools to improve our productivity in different parts of the development process.
• As the previous year, I continued to participate in our developers hiring process (helping with the job ads text, interviewing and assessing candidates). I think I am getting very good in guessing what are developer's abilities, pros and cons, just looking at a CV (though the candidate's code gives a much more precise picture).
• Mid-year I've returned back for a couple of months to my old duties as a Support manager, but this was temporary. The next year, I don't expect to do much of this type of work.
• Technology-wise, there were not that many novelties worth mentioning, besides me getting to know MS SQL Server much better. I participated in the endeavor of adding support for MSSQL for our applications (we supported only Oracle as a backend until this year). Learned a lot from this - the differences in the default locking models of Oracle/MSSQL were interesting. Although new technologies are now rarely introduced in our development, I am trying to keep up-to-date with everything interesting in our field. Besides the .NET related stuff, there are so many interesting things to follow, e.g. NoSQL. And of course, there's much more than the programming frameworks, libraries and tools, so a lot more to learn...

So this pretty much sums it all. Hope that the year 2012 would offer a lot of excitement and positive emotions.

On hiring entry-level/junior devs

I was recently asked about my opinion on adding some young & not-experienced people to our dev team, and after I emailed my analysis, I decided the topic is worthy of a blog post.

I’ll first start with the possible disadvantages of hiring junior devs:

· Might be very ineffective compared to more experienced devs, due to lack of necessary knowledge, skills & habits. Of course, attitudes & motivation also affect productivity. Btw, productivity b/n developers might vary significantly.

· Might require significant time (usually the time of senior devs) to train them & supervise them continuously (especially in the first several months)

· More people equals increased time for communication & coordination.

NOTE: When I speak of skills, I guess I should be more specific. Here are a few categories of skills that would determine how effective a developer would be at his work:

· Programming skills – ability to write/understand/debug/modify code efficiently (those include skills working with tools like the IDE, the source control + basic skills like touch-typing)

· Problems solving and design skills – ability to analyze (and redefine) problems, to come up with several solutions and evaluate what’s the best, etc.

· Learning skills – how fast can he learn new things and adopt beneficial practices

· Communication skills – how well the developer expresses his ideas (via code/documentation/e-mails/verbal discussions etc) + how well does he cooperate with others from the team + how willing is he to ask for help when stuck

· “Get into the others shoes” skills – how well he can understand what the client needs + how well he understands how his work is affecting the work of the team.

· Leadership skills – those are probably not software-specific.

 

Though most young people have probably not had the time and the opportunity to develop those skills, there are still probably several advantages in hiring them:

· Easier to find on the market (and cheaper)

· Motivated and energetic (hopefully)

· Free of bad habits – developers with experience are more or less shaped by their experience, and might have accumulated many bad habits that they’ll need to unlearn. Newbies can be molded into good programmers, if given appropriate tasks, attention, training & feedback.

Conclusion

I have a feeling that the best mix is with predominantly senior devs and ~20% junior devs, but I’m sure that other combinations could work fine too.

Summary of the year 2010

I somehow missed to write anything about 2009, but I am continuing my series from 2008, 2007, 2006 and 2005.

The most noteworthy change for me this year was my new role as support manager that I undertook for the last nine months of 2010. Initially the plan was just to substitute for a couple of months the person who recently got in charge of the customer support activities, but who had to go on-site to an important project. But I ended up doing this kind of a job for such an extended period of time. I was all the time trying to keep up with my work as developer as much as I can, though there were days when I couldn’t write code even for a minute.

It was a very different type of work. Definitely more stressful, especially in the begining. Unlike my dev work, it required often switching between tasks, quickly prioritizing where to put effort and where not. There were times I worked overtime by answering support tickets from home (before going to work or in non-working days), but the worse part is that often my mind continued to go back to the problems at work, even when I was trying to get rid of such thoughts.

The nature of this type of work was pretty demanding, as well:

1. It required deep and broad knowledge of many aspects of our products (I guess only a developer can have both).
2. It required knowing which of my colleagues to ask for assistance for particular customer issues (I admit I initially hated to delegate work that I though I would finish more quickly than anybody, but soon I realized that this is not always as effective as it seems).
3. It required an ability to quickly find out what is the customer really wanting and help him get it (either by directly solving his issue or thinking of clever workaround to get the job done in another way).

Often it felt very rewarding to help people solve their problems, and as an additional benefit my support work gave me a better understanding of how our products were getting used. This lead to better clarity what matters and what not, so I could concentrate on the truly important things.

Being the person responsible for the support, I strived to improve the process in several ways: by customizing the help desk software that we use, by educating our staff and our customers how to use it effectively, by trying to setup proper expectations and attitudes. There were numerous challenges and even several mini-crisis during those nine months. They definitely gave me a better understanding of the bigger picture. They also shaped my vision how things should be done in order to things to go smoothly. It was a valuable experience, but I am happy that I will be handing it back to my colleague, since I think that I would be more valuable in other areas of the product development. My passion for being a developer is stiill strong, but additionally I think I’m a person whose understanding of the product, the technlogies and the customer needs, could be used for architecting proper solutions for the areas that will make a difference for the company and its customers.

Besides this role of the support manager, there were other experiences that were new to me:

Going on a two-week on-site project – I went to Poland for an on-site work at our client there. I am not used to such type of work, but I think it went very well. Besides answering questions and troubleshooting issues, I also coded a few simple tools that help them solved some problems. The work was diverse and interesting, and it kept me busy all day. It was pretty exhausting too, so I am grateful that my lovely fiancé (now my wife) came for the second week to make my stay in Poland much more pleasant. It really helped me get my work-leasure balance back.

Interviewing candidates for a developer position – the last month I participated in several interviews (I’ve used to be only from the other side of the table). I was responsible for evaluating their technical abilities. Although the CVs gave hints about what the candidate knows and is capable of, asking proper questions sometimes revealed unexpected voids in the knowledge of people. Btw, in my first interview I was totally unprepared and didn’t know what to ask, but after some research on the topic I became more adequate to the task, though I guess I could be more creative. In addition to the interview questions, I also prepared a simple coding homework assignment that we were giving to the candidates. I am happy we used this approach since it showed pretty well how people approach code and what their skills are. It was also interesting to notice how differently people could try to code their way through such a simple problem.

Looking towards 2011 – I already mentioned what are my preferences about my career development for the new year. I hope that it will be a great year for everyone I work with. I wish my colleagues all the best, to keep it cool and to their best to maintain a friendly and supportive work environment.

Release notes – less or more structured approaches

Continuing my post from last week, I’ll briefly explain how we maintained a change log in my company for about an year (this was back in 2009) and what were the the things we liked and disliked about it.

We used a shared OneNote notebook that had a page per each internal build. After a developer had checked-in a bugfix or some new functionality, he had to describe the change in a free text format, Pasting screenshots was encouraged too, when applicable. The OneNote looked like that:

We chose OneNote because of its several conveniences:

• Easy to setup and use.
• Allows concurrent editing.
• Easily searchable.
• Allows WYSIWYG rich text formatting (including pasting screenshots)

Actually we didn’t use many OneNote features. It was just a visually appealing and easy-to-setup wiki. I think it was pretty useful for devs and QAs in terms of shedding more light in the product development. People could quickly got a good idea how features were evolving and be kept up-to-date with the changes in a non-obtrusive way.

But there were several things that were not that great about this process:

1. Some developers complained that it was getting too difficult to commit changes: first they had to write checkin comments, then they had to write a resolution in the issue tracking system, and finally they had to update the change log. Though the comment text could slightly differ, sometimes it seemed like a duplication.
2. It was not that easy assemble all the changes for the official release notes from the changelog. One of the reasons was that changes were organzied by date, while it made more sense to have them finally grouped by component and sorted by importance. Also the writing style of developers differs, so it was necessary to rephrase many of the changes.
3. Since the log has loose structure, it was not possible to query the changes, e.g. “find me the fixes by developer X made in the past 2 weeks”.

So I was thinking why not capture all release notes information in the issue tracking system itself. The advantages of such approach are obvious, but the system has to meet several requirements for this to work well:

1. Support custom fields (for a text field “DescriptionForReleaseNotes” and probably another one “ImportanceForReleaseNotes”)
2. Support specifying in which release was the change made.
3. Support specifying the component that changed.
4. Support generating a custom report that for any selected release(s) outputs the non-empty changes, grouped by component and sorted by importance.

I guess that most popuplar issue tracking systems would support the first three features. I have my doubts only for the report, but some systems might offer powerful enough reporting out of the box. And even if they don’t, exporting the result to Excel and doing some data manipulation there, is an option, too.

Another challenge is that this approach assumes that each item in the release notes should describe only one issue in the system, which is not always the case. You might want to group several small changes in one area in a single item. Well, you can just put a value in DescriptionForReleaseNotes for only one of them, but it will be difficult to manage this, unless there is a support for linking the other related issues to the one that contains the description. So linking issues is probably another requirement for this approach to work well.

So is it worth commiting to such a highly structured approach of storing release notes? I am not sure. If your issue tracking system can handle such process well, it might be relatively painless to adopt it. But if you have to use another tool just for managing release notes, it might be an overkill. What do you think?

Release notes – whats and hows

So you are asked to prepare a detailed list of changes in the last N months that would be the basis for creating the release notes for the brand new shiny version of your product. Unfortunately you have not been maintaining a change log throughout the product development. Naturally you can’t come up with a detailed list from the top of the head (even for the stuff you developed yourself). In order to do a decent job, several people have to invest hours (or days) to dig out stuff from various sources: the SCM system, the help desk, design documents, e-mails. Under time pressure they have to formulate the changes in a way that they make sense for the target audience. And if the deadline is tight, you might sacrifice the quality of the release notes. That’s stressful and inefficient. But before digging deeper on how to take preventive measures, let’s first take a look at what’s the purpose of release notes/change log and how to prepare them.

What is the target audience of a change log/release notes?

I initially planned to use the terms “change log”, “release notes” and “revision history” as synonims. But I have a subtle feeling that a change log is for internal audiences, while release notes/revision history are targetted to the end users. A change log also seems to have a connotation of an on-going effort, while release notes are often created just before the release as a one-time effort.

It’s clear that not only the end users (current and prospecitve clients) are interested in what’s fixed/ehnahnced/added. A lot of people involved in the product development need such information and they surely need it on a much more regular basis. The list of the internal stakeholders includes QAs, technical writers, developers, customer support, consultants, trainers, management. Probably everyone is interested in slightly different subset (or aspect) of the changes, but to keep things simple let’s examine for now only the differences b/n internal and external change logs.

Targeting external vs internal audience

The purpose of an external release notes (i.e. publicly visible & easily discoverable) is not only to inform, but most importantly (from the business perspective) is to:

• Advertise what goodness the new release brings – how does it empower the user (or at least alleviate some of his pain)
• Increase the confidence in the product and the company behind it - by demonstrating that serious efforts are put in its development and that there is a significant progress on many fronts.

The purpose of the internal change log is to make sure that everyone knows what is going on in the development and to take this in consideration while doing their job. It’s necessary to have additional information about the circumstances of the change (e.g. who was the developer behind the change, so he can be contacted later). The purpose here is just to inform (not to persuade), but still the description of each change should be done concisely from the perspective of the product evolution.

How release notes should be written?

I was looking for an answer of this question myself before deciding to write this post. I found several good answers at stackoverflow and in a blog post. But let’s first take a look at some sample release notes to have some background.

I spent a few hours looking at the release notes of a dozen of products (some of which I’ve used, some I’ve just been interested in). Here are a few links of various product types:

.NET control suites: Telerik , Infragistics, DevExpress, ComponentOne.

VS.NET addins: ReSharper, TestDriven.Net, Typemock, Entrian Source Search

SCM systems: Mercurial, PlasticSCM, Subversion, Vault

If you looked at the release notes, you’ve probably noticed that they differ both in terms of content and presentation:

Content

Highlights : more often than not, release notes start with an overview of the most important changes

Leaving out the bugs: some release notes don’t include list of fixes, but only improvements (or at least the list of fixes can be found in other not as easily accessible location). Since there is no bug-free software that I know of, I guess the this information filtering is geared mostly towards attracting new customers.

Level of detail: some vendors prefer to describe changes in the most laconic way possible, some are more descriptive

Automatically generated: some changelogs appear to be generated directly from the issue tracking system (or even from the source control system), but most of them look hand-crafted (especially in cases when rich output formats are used, e.g. pictures :) )

Presentation

Output Format: plain text vs richer format (HTML, PDF, etc.). Rich formats are more expressive & more visually appealing, but for some types of products a plain text change log might be just good enough.

Organization of the list of changes: usually the changes are grouped/sorted by component and/or by change type. The change types can be as basic as ADDED, IMPROVED, FIXED (see Telerik), though some vendors like JetBrains use more detailed types: Bug, Cosmetics, Exception, New Feature, Performance Problem, Usability Problem, Meta Issue, Task (as ReSharper).

Continued…

This post got rather lengthy, so I am continuing this topis in my next post with a brief analysis of what kinds of tools you could use for manageing change logs. I’ll share some of my experience and will discuss the pros/cons of different approaches.