The developers will rise up
Filed under: Crazy, Development, Management, Uncategorized
For those of you not from a technical background, dealing with technical people may seem a alien. This is the story of what happened when Cara (who reported into the sales organization) attempted to run a technical project.
I don’t recall Cara’s title, but she was the interface between the customer and the development team. We were working on a customization of our product for the customer, so there was a to be a lot of communications between her and the team. During the initial phase, one of our more cranky engineers was assigned to complete the project. Cara was new, we didn’t know anything about her. Mr. Cranky was in his heart a decent guy, but did not suffer idiots. Within two days, Mr. Cranky was complaining about Cara. We were not surprised about this, as Mr. Cranky complained a fair amount. About a week in, Mr. Cranky told his manager that he refused to work with her and demanded to be put on another project. No one in the development team was surprised.
Over the course of the next two months, it seemed as if the engineers were added to the project than left. After half of the engineers unsuccessfully tried to work with Cara, several engineers got together for a beer in the kitchen one evening to discuss Cara. They decided that Cara had to go. Several of the senior engineers approach the VP of development and told him of the problems with Cara and that the team was refusing to work with her. The VP listened to the issues and told the engineers he would escalate it to the executives.
After the escalation, they tried using sales engineers for the project. The sales engineers were unable to work with her either. The project ended up failing.
Cara considered engineers as interchange widgets and that engineers were a cast of “untouchables”. Her disdain for engineering contributed to her failure, but was not the root case. The two main problems which made it impossible for her project to succeed were a lack of understanding and a refusal to communicate.
The problem was that Cara could not communicate the proper requirements to the team. She would communicate requirements which were completely in left field. The requirements were obviously not something any customer would want. Development asked her for clarifications, and she would shout buzzwords at the engineers then return to her office. The development team attempted to get direct access to the customer, but she refused to allow anyone other than herself talk to them.
Cara was a one trick technical pony, she only understood one technical item, and mapped every problem into the one thing she understood. Cara joined our company and was placed on the project immediately. Her previous two companies were in the same domain, with those previous projects all using the one particular technology to solve the problem. Unfortunately, this time the problem (and the solution) were different. Cara didn’t understand the problem the customer was trying to solve, which doomed the project to failure. She could no longer keep spewing buzzwords at the team and get them to build the solution. Cara refused to seek help for herself (or the company) by allowing another person to communicate with the customer, which further contributed to the failure.
Build Systems
I hope someday to see a build system that is held together with more than twine and a prayer.
Developer Configuration
Filed under: Big Company, Crazy, Development, HR, Small Company
In a world where software developers spend 75% of their day at their desk coding, why is it that senior management goes cheap on the equipment? Here in order of importance are the items to provide your developers with a comfortable work environment.
-
Dual Large Monitors
Why is it that asking for two large monitors requires more paper work approval than a trip to Asia? Two large LCD monitors, maybe more, no less.Fast Computer
This may seem stupid, but many companies try to save a couple of hundred dollars when purchasing computers by going with slower computer and less ram. When it takes a long time to compile code, people are more likely to context switch to /. while waiting for it to compile. If it can be compiled quickly, developers are less likely to lose their train of thought.Comfortable Chair
If you are sitting at your desk for the majority of the day, spending the extra 1000$ for a nice chair. A developer once said about his chair, “You can have my Aeron chair when you pry it from my cold dead butt.” Over 1000$ for a chair seems expensive, but over 4 years (1000 working days) it is not that expensive. See Joel on software for his chair ROI calculation for the chair.Easy Meeting Room Access
A meeting room which can be accessed by developers without requiring them to book it ahead of time.
What I did not mention in here was offices. There is a large debate as to whether giving developers offices is better or worse, that will be left as a topic for a future post.
Sunshine Report
Sunshine Report: A status report which only reflects the positive feelings one is having.
For the most part, I have found that engineers tend to focus on problems in their status reports, but the first person who gave me sunshine reports took me by surprise. These next few paragraph detail my first enlightening experience with the sunshine report.
-
1st Status Report
When asked for his status, he responded that, “Everything is great, I’m looking into this one issue, but I’m confident that I’ll be able to get everything done on time.” My first thought was wow, a part of this project is going well. I recorded his report and moved on to my next task.2nd Status Report
I asked him for his status report, he said again that everything is good. He was still looking into this one issue, but is confident that fixing this issue will resolve many other issues he has assigned to him. According to him, everything will still get completed on-time. At this point, warning bells started to sound. I was concerned that he is still on the same issue and that this issue is starting to spread to other sections of the code. But, he still seemed positive about it. I let it go to see where he would get to next week.3rd Status Report
Now, this time I came to the meeting much more prepared. When I asked him how it was going, he was still one big happy ball of sunshine and confident that it would be done on time. I thought differently. He had just spent three weeks working on the same issue. I began to question him much more in-depth about his work. Driving down on the issues. After only about 5 minutes of drill down, he started to come to the realization that he was in over his head. We worked together to come up with a plan to get him back on track.
After that, I monitored his project more closely. Unfortunately on the next project, when prompted for a status report he still gave “Sunshine Reports”, but it just took a few minutes to cut through the sunshine to get to the truth.
Demo Driven Development
Filed under: Crazy, End User, Product Management, Project Management, Small Company
• Your company is living paycheck to paycheck.
• No one has actually paid for your product.
• Product direction changes each time sales visits a lead.
Given the above situation, it is time to plan a software release. The PMBOK doesn’t cover this kind of project. There is no chapter for near Armageddon events. Planning a software release for a company which is just starting out or in a death spiral is not covered in classical project management literature.
The development plan will be:
The name of the game is to make it looks like you have what the customers needs as quickly as possible. You do not know your market, you do not know your product, you know nothing. Through many failures, the company will discover the market. The hope is that there is enough time and cash to realize this goal.
Someone on the sales team manged to get on the calendar of someone with budget and a pain large enough that they will spend 1 hour to see if you can help them. The sales team has provided you with the release date, and a feature set.
As usual, break down the tasks, figure out what is possible, drop everything that is not (ensure that you record what was not done, and that it came in from sales, not the customer directly). Then get started. While developing it is important to remember that if you are successful, this demo will most likely become the foundations of your code base. Also, this software on demo day will not be touched by anyone outside of your company (in its current form), it just need to be good enough that they believe you can deploy it when they purchase it. I am not saying to fake the demo, I’m saying that you need to focus on the core pain points and that you can illustrate the solution to the potential customer. Many times, before the demo, the requirements will shift when the sales guys enlightens you more on the problem that the potential customer has. Those changes need to be incorporated. You are trying to demonstrate that your product can satisfy their needs. Do the changes as best as you can. Refusing to demonstrate a product which can help a potential customer is a waste of both your time and theirs. No one loves the churn, but you need to suck it up and do it.
During the demo, ensure that you are able to listen to the feedback while it is happening. This is the closest thing to users you have. They will provide you with the next set of work you need to do on your program. Record all their feedback (product ideas and bugs). Discuss internally all their ideas and make a plan for addressing the issues. Start working on them as soon as possible because you have up until the sales team schedules the next demo.
Once the next demo is scheduled, all of the focus shifts towards it. When demo goes well, but the potential customer is not interested (this is the most likely outcome), record all the feedback. Triage all of the features (including the previous demos) and begin work immediately based on what appears to be the most important in your potential customers eyes which is blocking the sale. Hopefully after several demos you will begin to see pattern and specific items and themes which re-occur. The future of the company depends on if you can solve the customers problem before the company closes shop.
Perspective
Filed under: Crazy, Development, End User, HR, Management, Small Company
This post started out as a discussion on the common enemy, Ted. Ted is the guy who everyone hates in the office and wonders why he is still there (If Ted is your CEO, it is time to look for a new job). As I thought about the Teds of the world, the theme of perspective kept coming up.
One of my Teds would constantly distract us from our work, arguing the peculiar aspects of a specification interpretation. We had no problems discussing these issues in six months, but while we were trying to fix data corruption bugs, a bit of perspective was required. I had to constantly recalibrate him. One incident occurred during crunch time in the early versions of the product. “Damn it Ted, it doesn’t matter how we interpret this esoteric section of the spec because it is meaningless until our users can load the work they just saved! We have been working crazy hours for the past weeks trying to fix the load bug so that there would be a company in six months.”
It is important when you are deep inside a complex issue, that you do not lose perspective. Many good engineers have lost hours on less important issues trying to work them out to completion. Always remember that It is important to keep the end user user in mind, asking yourself if this is the best way to move the product forward for them.
Release Notes
Filed under: Development, Management, Process, Product Management, Project Management, Quality Assurance, Templates
Software is never releases, it escapes. Usually when it escapes, it comes attached with a listing of caveats and other information for the user which are listed in release notes.
There is a big difference in the internal defect description and the external description. For instance, internally a bug may have the summary, “XML Parser occasionally dies horrible death when comment field improperly terminated”. The external release note could be, “The XML input functionality requires that the XML is well formed. Usage of poorly formed XML may result in termination of the application.”
The selection of content for release notes is defined by the culture of the organization and the relationship with the customer. I have been involved with the two extremes of release noting, where at one end we documented almost nothing, and the other we listed everything. When choosing your philosophy, keep in mind the following:
- Release Notes Leak
Each release note you write will end up in the hands of the sales force of the competition. Your competition will lie about your product, this just gives them more ammunition to confuse the customer and increase the duration of the sales cycle.
- Release Note Visibility
You need to know who has access to the release notes. Some release notes are published on the internet, while others are hidden inside of the product installer. If the release notes are visible to those who have not purchased the product, it may be time to get marketing involved in their creation as the notes could affect product demand. If the release notes are only visible to those who have purchased the product, you can be much more open.
- Does the customer care about this issue?
Yes, it is an important question to ask. Often dev will flag an issue for release noting because they think it is very important, but often they do not consider the program usage by the average user. I know that the program will crash if the XML being imported does not have the comment terminated, but I think it is safe to not release note this since the XML being imported is almost never edited by user. Development means well be asking for the release note, but after they have spent so much time working inside of the program, they often lose perspective.
- What happens if we don’t release note this?
There are consequences for customers finding bugs on their own. It is usually better for the customer to be provided advance notice of the issues so that they can plan their work flows around the defects.
- Will documenting this issue kill our chances of winning the product evaluation?
This is the one I hate the most. You should be proud of the product and acknowledge its short comings. The customer will find them out sooner or later. You will look more professional in the long run if you tell them the issues ahead of time rather than them finding them out themselves.
In one organization, I was specifically told not to mention any defects in the release notes because we were in the middle of product evaluations. This fostered a sense of mis-trust with the evaluators, who would constantly call and complain to me about the quality of the product. I finally convinced the organization to change their philosophy. Once we started producing real release notes containing useful information, their perception of our product quality by the evaluators actually went up. Before knowing the all the defects, they thought that almost all areas of the program were unstable. By telling them specifically what the supported scenarios were, it helped create trust and converted them from an evaluator to customer.
- Does this make the company and product look really bad?
If it makes the company look bad and the product bad, it is time to consider changing it from the “Non-Gating, Release Note” to “Gating”.
- Can this be explained concisely?
Why can the issue note be explained concisely? Perhaps it is to obscure of an issue to release note.
When in doubt, more is less. By trusting in your customers, they will trust in you.
A sample release note template is contained in the template section.
