|
We're All in the Same Boat Lisa Crispin dives into the "we're all in the same boat" theory and explains how it can't be more true in the software development world. From the need for common goals to going beyond taking responsibility for the team's actions, each team must know that you're going to fail or succeed together.
|
|
|
Use Uncertainty As a Driver Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions.
|
|
|
The "One Right Way" For those who believe there has to be one right way to do something, especially in software development - there can be. But that one way isn't likely to come from a single individual. Through collaboration and teamwork, some of the greatest single ideas have evolved.
|
|
|
Simplicity Before Generality, Use Before Reuse A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution.
|
|
|
Improve Your Communication Skills To Create Better Software Writing great software requires a lot of communication, and not just the client-to-server variety; person-to-person communication is crucial in a well-performing team. While it's easy to focus exclusively on improving our ability to communicate through the code we write, it's important to remember that building software is a communal experience: developers work with customers, testers, product owners, and other developers.
Here are some techniques and articles I use to reflect upon and improve my own communication skills:
|
|
|
Real-Time Problem Detection in Software Development Designing and developing software, it's usually cheaper to prevent problems from ever occurring (by making a decision at design-time) rather than patching them as they happen. But detecting problems in real-time is a useful skill in many professions, including one as different as recording audio books.
|
|
|
Flickering Test Failures and End-to-End Tests In "Growing Object Oriented Software Guided By Tests", Steve Freeman and Nat Pryce talk about the dangers of tests that occasionally fail, otherwise known as flickering tests. These failures can cause teams to start seeing these failures as false positives, and distrust their build results. I know - it's happened to me, especially with end-to-end Selenium tests.
|
|
|
Volunteering to Help and Learn At the Agile 2009 Conference, the LiveAid lab created an iPhone application to enable people to donate to the Mano a Mano charitable organization. This lab was an opportunity for participants to learn something new, practice their craft, donate their time to a worthy cause, and meet other folks. By the end of the conference, the application was working and had collected over $10,000 in donations.
Let's take a deeper look at these opportunities:
|
|
|
Personal Retrospectives We spend our time at work reflecting on our team's progress. We look for the root cause of problems to identify ways to make our work life better.
|
|
|
Can't We Just Be Nice? Lisa Crispin explains how being nice goes a lot further than just displaying good manners; it can be the difference between a happy, productive team, and one that's completely dysfunctional and prone to failure. Learn how she's discovered this on past projects and how you can avoid the same pitfall.
|
|