Are we there yet
Filed under: Big Company, Crazy, Development, Management, Project Management, Small Company
Asking developers on an hourly basis if they are done, will NOT make the fix come faster. Just because you are receiving pressure from above, doesn’t give you a license to kill productivity for all of those around you. Now is when you need to control the situation and get things done by helping your team. This is not the time to request for up to the minute status updates and TPS reports. Interrupting your developer’s concentration constantly doesn’t help them work. Try the following instead:
-
Make sure the correct amount of people are dedicated to the problem. There are many times when less is more (I’m not just talking about the editor), where the right two people are infinitely more effective than the wrong 20 people.
-
Distractions must be minimized to ensure their focus doesn’t drift from the current work to other priorities.
-
Provide the stakeholders with accurate updates on progress. If there is any heat or anger related to the issue, take it for the team so that they can focus on fixing the issue.
-
Ensure the developers understands the issue, context, and time lines.
-
Remove roadblocks soon as quickly as you can (or ahead of time if possible).
-
Get the developers what they need to get the job done right.
Clear the path in front of them and let them work, don’t hold them back.
The developers will rise up
For those of you not from a technical background, dealing with technical people may seem a bit 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 of them 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.
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.
Best … Demo … Ever …
Filed under: Big Company, Crazy, Development, End User, Small Company
There are certain aspects of a good demo, but it all comes down to practice, practice, practice.
Lets set the stage. After starting coding four month ago, we were running out of cash. There was a potential VC deal on the horizon, but it wasn’t going to happen until we had a sale. This was `the demo` to our only real customer in the pipeline. We had all the right people in the room for the demo. The customer had made it clear in our last demo what the sales objections were going to be, and that they had to be resolved for this next demo. It was a hail mary pass with two seconds left on the clock.
Lets dissect the days before the demo.
Day: t – 14
We gave a demo to our early adopter evangelist on the inside. He provided valuable feedback and pointed out the areas which will be the objection points. We scheduled the demo two weeks from that day. Several show stopper bugs, but we have two weeks to fix them.
Day: t – 13 to t – 3
Code like you’ve never coded before. Keep cranking it out. Don’t stop. Fix all those bugs.
Day: t – 2
We created the demo script. Although the meeting was to be 1 hour in length, the demo part was scheduled only to be 10 minutes long. The script covered all the users important pain points along with the requested objection points. All of the show stopper bugs were resolved except for one. We still have one day till code freeze to fix that nasty bug.
Day: t -1
24h before the demo was to begin, we froze the code. From now on, it was nothing but practice. That nasty bug is still there.
Now, about that bug. If an item was dragged in our interface, it would crash the entire application. Think BSOD. The only way to prevent the crash was to drag it to an exact pixel co-ordinates. Think of having a 1280×1024 resolution screen and having to drag to an unmarked x,y co-ordinate. If you missed, the application could crash and the company could fail. No pressure.
Day: t – 0
After our demo’er practiced nearly for a day, we were ready. He typically was able to hit the pixel about 50% of the time. Hedging our bets, I made sure we had two applications running at the same time, with the second setup to be at the exact point right after the crash should occur in the script. If a crash should occur, hopefully we can <ALT-Tab> before anyone notices. The demo went perfectly. He hit the pixel right on, no crash!
Best demo ever!
