Are you a developer? Yes? Then I'm sorry to tell you, friend: There is a Tech Lead in you. Rather, someone will try to make you a Tech Lead one day. For your future Tech Lead self, I recommend reading the corresponding articles, A Tech Lead Manifesto and Behaviours of a Tech Lead (written by colleagues Sam Newman and Pat Kua, respectively).
To those insights, I add these recommendations:
Know Your Teammates
Before you start, talk to everyone. Understand each developer's goals and fears with respect to your upcoming project. Know the strengths and weaknesses of everyone on your team, and formulate a plan for dealing with both. Sketch out your team roster and ensure that the experience and skill level is balanced.
Use Two-Pizza Teams
I'm not sure who first coined this, but I love the idea. I also like the idea of trying it out in reality: Have an in-office team dinner. Order two pizzas. Were you left hungry? Your team is too large. Or you have one gluttonous developer. But probably your team is too large.
Given an oversized team by this yardstick, work with all stakeholders involved to divide up the project. You may even find additional value in simplifications required to divide up your previously bloated project.
Develop Horizontally Until Release 1
It may seem obvious, but I'm still surprised how often this rule is ignored. If you haven't deployed into a production environment yet, build out -- not down. Complex business rules will materialize in every story. They always do. Create new stories from these rules and put them on the shelf until they are truly more important than the next functional story coming down the pipe.
As a Tech Lead, you share this responsibility with your stakeholders. At the end of the day, they will decide what is most important. However, the unseen complexity of a business is visible to you because it materializes as code; share this with everyone.
Build It Yourself First
All too often slogans such as "You Aren't Gonna Need It" are thrown around the the software community until they're almost law. Lately, I find the most troubling to be "Not Invented Here Syndrome"; more often than not, I find the opposite Syndrome afflicting developers: "There's a Framework For That! Syndrome"
Sure there is. Build it yourself anyway.
The majority of frameworks are simply implementations of patterns. Whether as ubiquitous as Dependency Injection, or as domain-specific as a shopping cart, try implementing the pattern yourself before reaching for the nearest third-party library. You very well might throw it away, but often you'll end up with an implementation which is significantly lighter and easier to test.
Keep Metrics and Ratchet Your Build
Chris wrote about "ratcheting" recently. Go read it! The flip side of ratcheting is, of course, preventative medicine. Why wait until you have 60 TODOs before breaking the build? Place as many reasonable limits on yourself as you can, early on. In the thick of the project your motivation to do so might be overruled by the desire to Just Write Code. Tools such as Panopticode, metric_fu, PMD, and Gendarme will help you a great deal, but they're just the tip of the iceberg. Be creative not only in the tools you choose, but the rules you write and the metrics you extract.
2 comments:
Gonna have to disagree with "build it yourself first". I understand your desire, but six years from now, the maintenance coders that take over your project will have no idea how your crazy DI scheme works, and they'll be cursing the fact that you didn't just use a well known (and well documented!) standard like Spring.
Six years from now you probably should have replaced your "crazy DI scheme" with Spring... five years ago. "You very well might throw it away" means that Spring and Guice are always an option.
I should add a qualifier here: "Build it yourself" doesn't necessarily mean "build it into the project" -- spikes and open source projects are good places to grease the wheels. Just make sure they turn.
Post a Comment