On Writing Tickets (Part 1)

Image(Right-Sizing Tickets)

Spoiler alert: I’m going to tell you right up front what my conclusion is: Tickets should be large in scope. Also, tickets should be medium in scope. Finally, tickets should be very small in scope. Tickets, tickets, tickets! Tickets for everything!

Imagine a ticket with the instructions “create user login.” Cringing? Me too. But most of us are familiar with tickets of huge scope that lack any kind of breakdown.

Back in the day, way back long, long ago (maybe not that long ago) we sent emails. “Hey Matt,” the email might read, “don’t forget to add the flim-flam to the doohickey. But don’t do this until the thingamabob layer is complete.”

We had defect tracking systems, but generally these were utilized for one of two purposes: Customer reporting of software issues, or quality assurance reporting of pre-release defects. Requirements were implemented by way of tracing through a document and checking items off of a list.  One of the earlier products for requirements tracking and traceability was Rational DOORS. There were a number of other tools we used, none of which integrated very well. Later I was introduced to Rational ClearCase, Rational ClearQuest, Microsoft SourceSafe, Bugzilla, Trac, CVS,  BugTracker, Subversion, Redmine, Jira, Confluence, Team Foundation Server… And on and on.

An early entry in the Rational suite of products, it was a rather expensive program in the way of licensing. If my recollection is correct, it seems that licenses were based on user seats. When such a model exists, and if each seat is expensive, a company may tend to limit the number of product users on a team. The side effect of this approach (again, only if the pricing is high) is limited usage within a team.  I recall project managers working on Gant charts, hosting meetings in which all the developers sat around a table gazing at a projected screen being asked for status updates on each line item. Talk about a yawn fest! Whether it was DOORS, Microsoft Project, some other tool, or a long list of line items with names attached to a number of tasks, the status meetings were always the same.

Some reading the list of products I just threw out will recognize that it isn’t very sensible. Some of the items in the list are used for version control. Some for ticket management. Some for a bit of both. Some of the products are no longer in use. Some are very old, but still in use. (And some, such as Redmine, Jira, and Confluence, aren’t all that old.) This was a problem then (and for many, it remains a problem now): The solutions to our development needs were viewed as separate entities. In addition, we just didn’t seem able to settle on how to use these separate items (which in the past, didn’t integrate well, if at all) in a way that actually helped rather than hindered.

In the early days of my career I almost always had an email inbox full of hundreds of items, some flagged, some marked as unread (so I wouldn’t forget), and some in the trash folder—either placed there deliberately or by accident. My monitor was littered with yellow sticky notes. A pad of paper next to my keyboard was packed with doodles, stars, asterisks, double and triple-underlines. If something was REALLY important, I may have drawn a box around it. For the REALLY REALLY important items, I drew two boxes. And for the REALLY REALLY REALLY important ones… You get the picture.

What a nightmare!

And let’s not forget the weekly status reports! I’m getting flustered just thinking about them! Well-meaning managers asked for status reports every Friday afternoon. When Friday rolled around, I often found myself digging through emails and flipping the pages of my notebook in an attempt to recall what I had worked on. Who has time to fill in a status report in increments each day when distracted by getting actual work done?  I loathed these reports. And I say this without hesitation, as I know I am not alone.

Inevitably, some line item would appear on the list with my name next to it. “Matt,” the project manager asked, “how are you coming with the doodad that implements the whatchamacallit?”

The other day someone asked me this question: “What are your thoughts on the difference between task-oriented and linear oriented?” It was an open ended question, so I wasn’t sure if this question was with regard to software functionality or design and development in general. I’m still not sure what the question means, but I assume it has something to do with the difference between viewing processes as a long line of things to be done in a sequence (with gates between each) and doing things as standalone tasks. Of course, even if something is ‘task-oriented’ there are still dependencies—things that require linear completion. This is why we write tickets that allow us to create a hierarchy of dependencies.

“Uh…” It seemed to happen every time! I was caught off guard by some entirely surprising task. My face felt a little warm, as I struggled to recall just what the hell the project manager was talking about. “Are you talking about the gizmo that ties in with the canootinator?”

“No! Not that… You remember, I sent you an email about the whatchamacallit and the doodad last week. It’s in my sent items. I’ll pull it up right now. Sure, I felt stupid. Maybe I should have. The truth of the matter, however, is that reliance on ineffective communication mechanisms is what led to this (not just for me, but for others as well). Sidenote: Being a software developer requires that one feel stupid every so often. It’s part of it.

As I write this, these recollections seem like the distant past—but the reality is that it wasn’t all that long ago.

(DOORS lives on as an IBM product. I have not used it in years, so I cannot speak to its current state of being.)

We’ve come a long way since then. Mostly. Maybe. Not all of us.

The subject I wish to write about today is effective utilization of tickets. It doesn’t matter what your development process is. Agile, SCRM, Kanban, some iterative process. Whatever the design and development approach—it’s high time to scrap the emails, notebooks, and sticky pads. Need I even mention that it is time to abandon the weekly status reports? (I’m not talking about sprint planning or standups when I say this). I don’t care what the development approach happens to be. Whatever it is, granularity of tasks, detail, and communication remain absolutely necessary (and email does not qualify as effective communication).

Should someone—from your boss to your boss’s boss to a well-meaning coworker, come to the door of your office, cubicle, desk, or couch with the expectation that a conversation is locked in as a done deal upon leaving—shame on all involved!

The same goes for IM and text messages. None of the above forms of communication should ever be considered a final lock-in of a task. There is one and only one way that work items—any work item—should be recorded: The ticket management sytem.

There are many too choose from, some better than others. The poorly-named BugZilla is a fine choice, but Team Foundation Server, Jira, Redmine, and Trac are all great options. Redmine and Trac are entirely free, and they are great tools with plugins for everything under the sun. My personal preference is Redmine, but this could be a bias simply because I have used it so much.  Before I continue, let me make one thing clear: Let’s never again refer to a ticket management system as a ‘bug tracker.’ NAY! To call it a defect tracker leads us back to square one. A defect is a category of a ticket. It may be something of high priority—but all tickets should have an associated priority.

There are a few integrations that I consider absolutely necessary. To make a ticket management system effective, it must integrate with:

  • The  CI (continuous integration) build

CI should integration with version control. It should pester the team when a build breaks. It should make it clear what changeset broke the build, and the changeset should point us to the ticket that was being worked on that prompted the changeset.

  • Email

Wait—didn’t I just say we need to scrap email? I did. Email is a good prompt, however, for team members to see new and changed tickets. For a small team, I like to see all of those emails, even if the task is not related to me. It’s good to know what others are doing.

  • Version Control

Changesets must be concise. As we check-in for commit stuff to our version control (by stuff I mean anything—not just code. That stuff could be configuration files, documents, spreadsheets, etc.).

  • Existing workflow (and if we have to shoehorn the concept of tickets into the workflow, perhaps it is time to rethink things.)

I’ll keep this on-point, as much as I can, as I see a great deal over overlap among the necessities (and for this blog I’ll be writing separate posts (lest my faithful readers become distracted while reading too many words).

Mistakes

soupThe other day my daughter wanted to heat up some soup in the microwave. She insisted on doing it herself. The lid of the Campbell’s Soup can the type with a tab that can be opened without a can opener. She stood in front of her mother as she attempted to open the can, wrestling with it a little. “Lift the tap up, and then pull on it,” her mother instructed. She added, “I really think you should open it in the kitchen over the sink.”

My daughter struggled with the lid, but still didn’t want help–she wanted to prove to us and to herself that she was capable. Soon enough Campbell’s Double Noodles were spilled all over the floor and her mother. Oops.

Did we get mad? No way! How could we? We knew the possible outcomes, but we also knew that we had to allow our daughter to figure this out. My daughter learned a few things in this situation:

  1. How to open a can of soup.
  2. What can go wrong if you tip the can sideways while opening.
  3. Why she should have done it over the sink.

Continue reading

Boss vs. Leader

I’m not sure where this image originated from, but I like it.leader

Do Not Flounder (Stay Un-bored)

The following is an article that I am working on for a yet-to-be-determined publication. Having done this before, I will say that getting an article published in a journal/magazine isn’t as difficult as one may think (as long as you have something to say). This hasn’t been proofed, so please forgive any typos or errors. This article is not about the role of management. I would like to follow up on that subject, because I do think management can and should help to produce great software engineers. I’ve seen otherwise good programmers flounder under lacking management. It happens. This article is about the role of the developer, the individual contributor, in making sure that his or her career starts of right and continues to grow.
One ore note: The original version of this post was written in about 2 hours and was full of errors. I’ve applied a number of corrections, but it will likely be further edited before publication.

I have no idea whether or not most developers using Agile have actually read the “Agile Manifesto.” Here it is:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

This post is more about career growth than Agile, but somehow I think the Agile approach is relevant here. Agile, as we know it, is an approach to software design. It can also be an approach to managing one’s own career.

Floundering

A friend of mine recently said this: “Your attitude determines your altitude.” Although he was speaking in a general sense, I couldn’t help but think of the application of this motivational advice in relation to software engineering. It is relevant because as software engineers, our career growth is in our hands—perhaps to a greater degree than in any other field. Continue reading

Success as a Technical Lead – Article

I stumbled upon this article today. Its a little dated (from 2008), but still relevant. I don’t think the list is comprehensive, and I certainly think other technical leads would have varying opinions on things. All of the points listed are good, but there are a some points that really stand out:

6. Be part in the design of everything
This does not mean do the whole design. You want to empower team members. But your job is to understand and influence each significant subsystem in order to maintain architectural integrity.

7. Get your hands dirty and code
Yes you should take parts of the code and implement them. Even the least glamorous parts. This will help you not getting stuck alone between management and the team. It will also help you gain respect in the team.

20. Don’t blame anybody publicly for anything
In fact as a tech lead you cannot blame anybody but yourself for anything. The moment you blame a team member in public is the moment when the team starts to die. Internal problems have to be solved internally and preferably privately.

24. Mentor people
It is your job to raise the education level of your team. By doing this you can build relationships at a more personal level and this will gel the team faster and harder. It is very effective with more junior people in the team but there are ways to approach even more senior members, just try not to behave like a teacher.

25. Listen to and learn from people
Even if you are the most experienced developer on the team you can always find new things and learn form others. Nobody is a specialist in everything and some of your team members can be domain specialists who can teach you a lot.

28. Be sure you get requirements and not architecture/design masked as requirements
Sometimes business people fancy themselves architects, sometimes they just speak in examples. They can ask for technology XYZ to be used when what they really mean is they want some degree of scalability. Be sure to avoid hurting feelings but be firm and re-word everything that seems like implied architecture. Get real requirements. To be able to do this you have to understand the business.

36. React to surprises with calm and with documented answers
Never get carried away with refuses or promises when confronted with surprises. Ask for time to think and document/justify your answers. It will make you look better and it will get you out of ugly situations.

A theme throughout the list, and throughout a number of similar books and articles with such advice, is that a good technical lead appreciates and values the various talent and particular skills of the team. A great technical leader isn’t necessarily the “know it all” of the group. He or she should certainly be skilled and eager to maintain that skill–and even be a great developer. But smartest person in the room? Maybe. Maybe not. Personally, I like working around people who are smarter than me. This is the best way to learn.

And there’s a flip side to number 20: Don’t blame people publicly for problems, but be quick to praise people for successes, major and minor. A sense of recognition for one’s diligence is tremendous motivator. I don’t know a single person who doesn’t appreciate kudos. Most parents realize that their children respond better to positive reinforcement than negative… This doesn’t change when one reaches a certain age. I’m not suggesting that a team member not be confronted for problems. Of course he or she should (and must).

Very recently a company-wide email spoke of a major success of mine (successful deployment of a year long project), and mentioned me by name. It felt great, and it made me want to continue with even more success (and it was a great confidence boost). Simple put, its good to know that the folks at the top of the organization are aware and appreciative of the work of those in the trenches!

This all may sound like a lot of feel-good fluff. It isn’t.

Little Tutorials: 36 Steps to Success as a Technical Lead

Version Control/Wiki Control

I FIRMLY believe that documents related to a project should be managed in the same version repository as the source code. This gives us a snapshot in time of all items related to a project. The problem with this comes when using a wiki (and I love using wikis, so don’t get me wrong). There is no way, if we are using a wiki page for specs, requirements, etc., to link a wiki instance in time to a Subversion (Git, Mercurial, whatever) instance in time.

And I don’t think we would want such a feature anyway. A wiki covers many projects and many team needs, not just the needs of a small group of programmers on a single project. I can’t imagine “rolling back” an entire wiki to a given snapshot.

I wonder if there are any clever ideas out there for handling a need such as this. I can see the possibility of pre-commit hooks being used to label wiki pages, but this seems cumbersome (if not entirely unmanageable). The other solution is to rely on the wiki only for collaboration and not for official documentation of any kind. This approach, unfortunately, cripples much of the power of using a wiki.

I am open to ideas.

6 Developers, One Room

Under an extremely tight deadline one team member decided that it would be best if the developers took over a conference room. On a long conference room table there are 6 computers, and 6 extremely talented developers chat, joke, brainstorm and work away. The manager of the team is there too, explaining requirements and helping to clarify definitions and functionality.

There is pizza, too.

Its like that scene in Apollo 13 where the engineers have to figure out how to get the Apollo back to Earth. Ideas bounce freely and communication is immediate. I don’t have to wait for a response to an email or a response in a chat window (which may or may not come). And there’s something about sharing a space with a common goal: The team seems to gel. There is little or no arguing or passive-aggressive commentary as I have seen in meetings throughout my career. We’re all in this together, after all.

I’ve never seen software written with such efficiency.