So which platform is better? Is it Java or .Net? The answer might be in this new movie coming soon to a theater near you. Check out the trailer.
Wednesday, June 30, 2010
Friday, June 25, 2010
Code Leaders and Beautiful Teams
At QCON London 2010, Roy Osheroveshared shared his experience of working on great teams.
He discussed things that good teams do:
- Automate everything: Configuration, deployment, builds, and tests.
- Test and buy the right tools: automation tools, bug management, source control…
- Throw out the wrong tools.
- Master your tools: shortcuts, macros, refactoring. A good exercise is to try working without a mouse for a couple of hours.
- Get quick continuous feedback from tests and CI, from customers, from peers
- Show big visible process: Have a whiteboard.
- Communicate without meetings: stand-ups, pair programming, peer code review, team rooms, and visual progress.
- Visual board: Create a metaphor for your system and put inside it the components of the system and color code each process.
- Code reviews and test reviews before every check-in.
- Build by feature and not by layer.
- Small team, same room, big feedback.
Then Roy covered things that good team leaders do:
- They are bottleneck ninjas. Sit in the same room as your team. Be aware of the conversations going on and problems that arise and step in when necessary.
- Grow people with integrity.
- Remove obstacles and help the team on how to remove their own obstacles. Ask them to find solutions.
- Connecting it all.
Roy recommends that these be used as a check list and be reviewed on a daily or weekly basis so that the team and the leader continue to improve.
Thursday, June 17, 2010
How about a Game of Ping-Pong at Work?
That's ping pong programming of course. It's a combination of Test Driven Development and Pair Programming. The 1st developer writes a test and then passes the keyboard to the second developer who writes enough code to make the test pass and then writes a second test and passes the keyboard back to the 1st programmer who in turn writes enough code to make the second test pass and then writes a third test and so on. This keeps both developers involved and focused. What do you think? Ready to give it a try?
Thursday, June 10, 2010
Bad Code, Craftsmanship, Engineering, and Certification
At QCON 2010, Robert Martin gave a talk about Bad Code, Craftsmanship, Engineering, and Certification. Uncle Bob started the talk by showing an example of bad code which consisted of two massive classes with hundred of methods. He asked why do we write bad code that we know will impede us? And wondered if it is due to deadlines, laziness, boredom, or job security. Bob stresses that the way we go fast as professionals is to do the best job we possible can. He encourages us to wear a green band on our wrist that symbolizes a commitment to write the best code we can at all times.
Uncle Bob then makes the following recommendations:
1. Apply the boy scout rule: Always leave the camp ground cleaner than the way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.
2. Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract the function. This takes all the concepts in the function puts them in well named places.
3. No argument is the best argument. Functions should have the smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.
4. Use long names to be as descriptive as possible.
5. Avoid duplication. Do not copy and paste.
Next Uncle Bob goes over the Software Craftsmanship Manifesto which states:
1. We value not only working software but also well crafted software
2. Not only responding to change, but also steadily adding value.
3. Not only individuals and interactions, but also a community of professionals.
4. Not only customer collaboration but also productive partnerships.
He then covers the disciplines that the manifesto is based on. These include:
1. TDD – verifies that our code works and also makes it possible for us to refactor and constantly improve the code over time.
2. CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If the build fails, immediately fix the build.
3. Pairing: If you don’t want to code pair, at least make sure the team is communicating, sharing and working closely together.
4. QA should find nothing
5. Have pride in workmanship
To convince others, the best thing you can do is do the best job you can and be a role model. Soon others will observe that you are outperforming the rest and will realize why.
Uncle Bob next covers the engineering practices of small cycles feedback, source code as the design, and design patterns. He wraps up by discussing certification and how they over promise and under deliver. Instead he recommends actually talking to potential new hires and have several team members talk to them as well. Let them show you code samples. Ask for references and check those references.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code
Subscribe to:
Posts (Atom)