Live blogging BizConf Day 2
Day 1 of BizConf was phenomenal and I’m going to try and keep up the live blogging for day 2. I missed the lightning talks last night but heard great things from everyone who went. I’ve got my camera charged up today so I’ll try and get some pictures of the presenters as well. Fair warning: I’m really not that great of a photographer.
- Roy Singham’s keynote
- Corey Haines: How Agile Will Probably Fail You
- Bruno Miranda: Successfully Managing Local and Remote Teams
- Agile, Rails, and the Cloud
Roy talks quick! I had some trouble keeping up with the wealth of information coming from this talk.
Randomness is a much greater predictor of success than skill. Decoy pricing is probably used a lot by consulting firms. It’s easy to compare a distorted version of something to the non-distorted version than to something else.
Think about your leadership. Write down your top 10 mistakes. Put them in to categories. People mistakes and investing in the wrong person. How you handle yourself in a crisis. When confronted with a huge number of decisions, how do you handle it? Are you confident?
A mistake is something you made in hindsight, not in foresight. The sign of really great leaders is to protect people who have different skills. You have to have people who offset your own weaknesses. Not trusting his gut about a certain person in his organization cost the company a lot of money. Even though he had a gut feeling about this person he forged ahead. Always trust your gut.
There’s no bonuses at Thoughtworks but leaders still focus on money. Even though we would like to believe that sales are driven by supply and demand, we’re closer to ducks. Take the iPhone as an example, and Starbucks coffee. Starbucks is not worth $5/coffee but we’ve been convinced it is. That’s how a lot of consulting companies charge exorbitant amounts.
- Are they good at their job?
- Does their boss recognize it?
- Do they have friends at work?
The average 23 year old expects to have 12 jobs by the time they are 30. That’s almost a job a year.
Roy’s ideas for surviving a recession:
- No matter how smart you think you are, you will still make mistakes.
- Massively increase sales force.
- Double intimacy with customers. Get closer to them. Understand your customer’s customer. If you can understand that, you will create more value for customers.
Take the biggest risk you can possibly think of to create new business strategies. Learn quickly, make it something you can live with. Thoughtworks is engaging five simultaneous new offerings.
A huge limitation of why we fail at software consulting is that people in the software industry aren’t generally aware of how their clients are feeling emotionally.
Think about what you want to be known for when you get older. Make a difference you will be proud of. Success should not be about how big your company is. It should be about how you change peoples lives.
Corey Haines of coreyhaines.com
If you’re not familiar with Corey Haines, he’s a "software journeyman." He travels around and pair programs with people all over the country. I’ve had the opportunity to pair with him for a day and it was quite an experience.
Life rule #1: Any time you get to go to the scientist only section, you say yes.
Why do we write bad code?
This is not the question. No one likes to write bad code. The question becomes the following:
When do we write bad code?
When we’re under pressure and have to get it done. The deadline is coming and you’re only 80% done. There’s only so much time left so we start hacking away. "Get it done"e; vs "Do It Right". There’s a perception that when you have to get it done the only way to do it is to hack away.
Here’s an idea: if we have developers feel like they’re under pressure at the end of the project, let’s change the deadlines to every month. It would be great if we could let everyone figure out their own process. When people think of agile this is what they think of. Yet the issue of "Get It Done"e; vs "Do It Right" is still an issue. Most young people, in terms of a development perspective, only think about today. Scrum assumes that developers self oganize and are responsible.
Features and Quality
Let’s talk about features. Add a feature to your app. Change a feature in your app. Then time passes. As you work with crap code it takes more time to add features. This brings us to a definition of software quality: having a nominal cost of adding new features. It doesn’t mean there will be no bugs.
Software can be similar to gardening. Gardening isn’t about growing plants. It’s about changing the environment to let it flourish. Add a feature then clean it up. Change a feature then clean it up. Make sure your code base stays clean and boring to add new features.
"If I’m adding a new feature I don’t want excitement"
Why doesn’t everyone do the XP techniques?
We don’t know how. They’re hard to learn. While learning to do TDD a friend of Corey’s took a 70% hit in productivity. So how do you learn to do XP? Most small businesses can’t take that hit in productivity. Work is not practice.
Becoming a better software developer is about practice. How good would a band be if they only practiced while they were on stage? What kind of quality would a play have if the actors were only given the script an hour before the show? Enter the software craftsmanship manifesto.
- Code Kata
- Coding Dojo
- Code Retreat
- Acceptance Test-based
In the end I think it boils down to this: developing quality software is about taking pride in your work. The software craftsmanship manifesto gives you guidelines. The practices outlined above get you better at it. Take pride in your work and write quality code.
During this talk Jerry got in to a bit of a debate with Corey on practices. While the debate was lively and interesting, this probably could have waited until his talk was over rather than taking time away from Corey’s talk. There was about 25 minutes worth of content Corey didn’t get to. I’m going to be forced to find out about the rest of the content of this talk over scotch later. The horror. I’ll update this post later.
Bruno Miranda of Hoodiny Entertainment
Cyloop is a music site. The first version of the site was in Java. It couldn’t scale. The CEO of the company decided to switch to Rails and hired Hashrocket. They did the 3-2-1 launch. Hashrocket taught the developers, who were all Java, .Net, and PHP developers, about TDD and Rails. Hashrocket’s time lasted about a month. The app was re-launched in about 3 months total.
Having a local team is important. You have a lot of bandwidth to talk and communicate. It can also be distracting. The team uses headphones a lot to reduce distractions. It’s good to have the stakeholders in the same spot as developers. There’s five people in the Miami office, one in Orlando, and remote developers in Brazil. The team tends to type rather than talk, even in person. Typing tends to keep conversations more succinct.
Why go distributed? Bruno wrote a post on his blog about limiting yourself. The Ruby community is small and there’s not a ton Ruby talent in Miami. They would rather not limit themselves to just local talent, they want the best developers. Do video chats to hire people over-seas. Use other resources to find about people. Look at their GitHub accounts. It’s all about finding the right people and staying transparent.
Working with local and remote teams is about transparency. If you don’t know what someone is doing then how do you know they’re doing anything at all? If you don’t have a lot of throughput to talk to people face to face you wind up getting a lot of phone calls and meeting requests. Skype and AIM are “silo” based and talking one on one is probably going to be beneficial so move it to Campfire. Mac folks, check out Propane so you can get your name growled.
In another company, Bruno tried daily standups via phone and Skype but you always waste time getting the mic set up. Daily standups are done in camp fire. Standups are a one paragraph conversation with the rest of the screen. There’s a script that calls for the daily stand-up every day in the Campfire room. Don’t let your standup become a book. NewRelic notifications and incidents get automatically posted in to the campfire team room as well. There’s mainly one product with this company and you may want to move individual projects in to their own room.
They don’t pair all the time. They pair over iChat and Skype. Skype has better sound so disable the mic in iChat.
Projects are managed in Pivotal Tracker and meetings are done with the person who makes the decision. The whole local and remote teams are not included because there’s too many people. There’s a lot of streamlining of the communication process in this company. Your company has to be able to accept change to pull this sort of strategy off.
There’s a strong misconception that you can’t manage a local and remote team. It can be done and it can be done successfully, your organization just has to be willing to accept change. It makes business and financial sense and as long as you get the right people you get quality code. Bruno did a great job with this presentation and made some great points.
Ian McFarland of Pivotal Labs
As developers, we build software because it’s cool, fun, exciting, and we love the challenge. Also it beats a lot of other jobs. Companies build software for different reasons. They do it to save money, manage risk, and satisfy business and government requirements. We’re in the middle of a revolution. This revolution in software is about one thing: building better value for businesses for lest money.
Software is expensive. The following are the most expensive with developing software: developers, defects, deployment, maintenance, and change. In the current economy budgets are smaller, the stakes are higher, departments have to do more with less, and failure is more catastrophic.
Agile is business driven: requirements come from business stakeholders.
- The customer is empowered to make decisions and priorities are set by that customer.
- The customer can change priorities on anything unstarted.
- The customer accepts the work in fine-grained increments.
- The customer is intimately aware of progress and projected feedback dates.
- Closing the feedback loop is critical.
TDD and BDD factors in to this. Good tests tell us when we’ve met the customer’s needs, what’s broken, and lets us refactor. TDD helps keeps you focused: you’re not building features if you don’t need them.
A big part of agile is iterative development. These days, iterations are getting shorter. Because the customer is seeing the work on a daily basis, the feedback cycle is short. This keeps the cost of change low by preventing unnecessary work.
Continuous Integration and Continuous Releasability
There is a bit of a misconception about continuous release. Just because you can release continuously doesn’t mean you have to release continuously.
You have to pair if you want to be as efficient as you possibly can. As long as there’s more than one developer you’re already pairing. Doing it all the time means you get better at it. Pairing is effective because you stay focused. Developers can get distracted. It’s hard to stay focused all day. At Pivotal developers are exhausted at the end of the day their first week on the job. This is because they’re really not used to coding non stop for 8 hours a day.
Pairing helps because you don’t get stuck so you spend more time on the more interesting part of your code. Developers get more well-rounded as they pair. You learn from your pair — design and testing techniques, new development techniques, etc. As a business owner you’re investing a lot in your developers this way. If you’re not pairing you’re throwing that away. New team members can be brought up to speed in an hour when pairing rather than taking a week to figure out their way around. Another benefit to pairing is that you distribute knowledge more. Your bus factor (the number of people who need to get hit by a bus for the project to stop) goes up.
You need to make a productive workspace in a pair environment. Have consistent pairing stations. Pivotal will have breakfast available before the morning stand-up. The reason is that some developers wouldn’t eat breakfast before work and some would. This would result in some developers wanting to stop earlier for lunch than others.
Developer happiness is important to the business. Having a happy developer is important because developer happiness is directly correlated to developer productivity. Productive developers tend to be happier. When you’re doing grunt work as a developer things don’t seem as bad. Happy workers are more focused.
Rails is powerful. Rails goes very well with agile — it’s practically baked in to the culture. Anecodtally, Pivotal has seen a lot of improvements in efficiency with Rails.
You don’t have to worry about buying hardware anymore. You don’t have to be in the infrastructure business. You can scale on demand if you architect for it. You can stay focused on development. This is a big change in the industry.
The enterprise is not quite cloud ready yet. Lots of CIOs really want everything running on ahrdware they already bought. There are sometimes legislative restrictions about having things in the cloud. But it’s getting better. People run HR, CRM, and financials in the cloud now. The cloud is getting closer to being enterprise ready. There are market pressures being addressed every day by cloud offerings. These are all problems we’ve heard before.
In the end, it’s not about the technology. Businesses don’t care about technology. Technology is the means to an end. Think about the technology like a business. Think about getting it done cheaply, quickly, and well. This is why Rails, agile, and the cloud make business sense.
Jose Gonzalez of Hoodiny Entertainment
Other than what you’re going to provide, when you’re going to provide it, and how much it’s going to be fore, everything is going to be specific for your business. Don’t accept sloppy code and don’t accept ambiguity in the business. If you and your client don’t understand what it means then a judge won’t understand what it means.
Under the law trade secrets are protected as long as they are secret. If you come up with something that is a trade secret the very nature of its protection is associated with its confidentiality. On the other end of this is patents which require you say as much as possible in order to obtain protection. To mark it as a trade secret it must be marked confidential. Do not let anyone see it who doesn’t need to see it. If a client has given you something that is a trade secret it should be market as confidential.
Some companies will put everything as confidential. Some judges will toss that out as a matter of course. As a consultant, everything you learn while in the client’s office should be treated as confidential. That’s just good practice.
If you write the same ten word essay as someone else, both people retain the same copyright. Copyright is the right to stop somebody of copying your work. If you have created something independently from another person then you are not copying.
Trademark isn’t there for you. You need to fight to keep it.
If you’re going to do business, do safe business. Get business insurance.
It’s a little thing at the bottom of the clause. Anything that anybody said prior to executing this contract in oral communications, written, etc, is gone. If it’s not in the contract it doesn’t exist. Basically, if you want something. Particularly for consultants if there were conversations you had with clients prior to the deal, put them in the contract or they don’t apply.
Understand the Client’s Organization
If someone is the CIO and they hire you, you generally don’t have to worry about hiring issues with them. A CIO would have "apparent authority." You need to make sure that the person who is signing the contract with you is authorized to sign the contract. He jokes that in a bank everybody is the vice president. Don’t negotiate with someone who is seven levels down in a company. You may have already given someone your best deal who has no power to execute on it. Understand the layout of the company before you make a decision otherwise you will be spending a lot of time and energy that might not even apply.
- If you’re going to make a statement of work they should only have statements specific to the business and scope of the work. There may be times when you come up with a situation where you have an agreement where you have to change something with a specific deliverable.
- SLAs are nothing more than a way of limiting liability in a specific circumstance. Be careful with them. If the SLA doesn’t meet what you’re looking for it overrides liability. Make sure you understand SLAs.
- If you need something from the client in order to make something happen put it in the contract. Outline the client’s responsibilities.
- It all comes down to this: protect yourself. See a lawyer and get a contract made.
Overall this was one of the most useful talks so far of BizConf. Jose thoroughly knows his stuff.