Just for fun, I’m going to try to keep each section under 3-4 sentences, and finish in under an hour.
That’s bookkeeping, not project management
JIRA, Microsoft Project, VSTS, whatever. Fiddling with a project management tool is not project management. Project management is communication, analysis, risk management, and getting me the stuff I need to keep coding! Don’t tell me project milestones or tasks in a tool. Let’s determine milestones and iteration plans collaboratively in an iteration kickoff. More interaction and communication and less bookkeeping.
How do you not know?
I listened to the DotNetRocks episode featuring the VSTS panel at TechEd the other day. Part of that conversation bothered me a little bit. The panel addressed a question about using the metrics generated by VSTS on developer checkin’s to make quantitative judgements about the relative productivity of the developers on a team. I thought the panelists were fairly good about saying that the metrics should merely inform the judgement of productivity and named a couple reasons why the metrics (code checkin’s, code churn, whatever else) could be skewed to give you a false impression (and I can think of a couple dozen more, not the least of which would be pair programming). That’s fine, but my immediate response was how the *&^%%$ do you not know exactly who your most and least productive developers are? Even without statistics and software engineering, how the heck are you not intimately aware of your team and each of your teammates? I don’t buy the big team/big project argument because those projects are just divided into a team of teams. What gives?
Stay on Target!
My colleague got a little object lesson today in priorities. At almost all times, you need to stay focused on the highest priority feature. Any effort you spend on unnecessary frills or low priority features is time and energy that isn’t spent on higher priority tasks. It sucks some of the fun out of development, but the guy paying the bill needs to be kept happy. You’ve only got so many units of developer time to play on the project. Use them wisely.
The Last Responsible Moment
In a related topic, last week I did a review of our system to the developer who’ll likely be in charge of the system after I bow out. I showed him our scheme for plugging in new types of trades into our WinForms app. Right now it uses a C# fluent interface that’s nothing but a thin layer over the StructureMap configuration API. He challenged me on why there wasn’t an option to plug in new features by simply deploying an extra assembly and making an Xml configuration change. My response was that there wasn’t a requirement for that. It does sound like something that might be useful in the future, but any time spent on that feature today takes time away from the things that are necessary now. In terms of the Last Responsible Moment, however, we’ve left the door wide open for making that feature possible in the future. By no means have we eliminated the possibility of pure xml extension. Things just don’t have to be perfectly future proof when you’ve got reversibility. Code and design in a way that leaves the door open for extension and modification later and you won’t have to kill yourself getting it perfect upfront.
YAGNI for Enterprise Architects
I came to a realization today on one of those strategic versus tactical decision points. We decided early on to persist data in the industry and client standard Xml format. The horrendously convoluted not meant for human consumption Xml format. Why did we do this? Well, because in the future it should make it easier to communicate with external systems and it’s the standard by golly! I thought it sounded like a good idea, with a minor caveat. In the end though, that decision has caused us a significant amount of extra work with zero payoff. With an Xml format that complex you can’t say that you’re ready to integrate with another system until you’ve tested the Xml payloads anyway. If we’d gone with the alternative of just serializing the Trade objects to a simple Xml format, we would have save a lot of time while still delivering the immediate business functionality. I think we should have YAGNI’d that decision. The Xml will almost certainly need to be tweaked later for the downstream systems anyway, so all we bought ourselves was an extra headache. And compliance with corporate guidelines.
Dogfood It
Process, design, or framework. It just shouldn’t be trusted at all unless the creators dogfood it. You need to feel the pain of your decisions.
If/Then Klooge is my Coding Horror
Jeff “Coding Horror” Atwood recently wrote a post criticizing the usage of design patterns as unnecessary complexity. While patterns can definitely add unnecessary complexity when used inappropriately (just about any use of the Singleton anybody?), I’m going to disagree with Jeff. If you take a close look at most of the original “Gang of Four” Design Patterns, you’ll see that many of the patterns are aimed squarely at:
- Reducing the amount of branching constructs in the code. Switch statements and deeply nested if/then statements are to logic bugs as stagnant water is to the mosquito population
- Eliminating duplication
- Decreased coupling
- Separate concerns
All of those bullet points seem like good things to me. Maybe you just simply ask yourself if a pattern helps you before you use it. I know many people have a near knee-jerk reaction to design patterns, but if you ever work for me I’ll verbally abuse you for deeply nested code and repetitive branching logic. I’ve started to walk up and down the row of cubes just muttering “Control-Alt-M.”
There’s a strain of Extreme Programming practitioners that seems to believe that “simple” means using nothing more sophisticated than throwing if/then statements against the wall until unit tests pass. Then, once it’s so obvious that a casual observer is appalled by the state of the code do they start some refactoring work. Don’t be like that.
My latest hypothesis for the development skills shortage
I think most of you will agree with me that there just isn’t enough developer talent out there right now, and I’ve got a little theory about why this is. I just interviewed a trio of candidates with about 10 years of experience on average. A couple of them might be okay with some coaching, but on the whole all three seemed rather weak
Fast way to blow an interview with me
I knew within 5 minutes that I was rejecting a candidate, but I try to give everybody a chance. This particular candidate had bombed some basic .Net trivia before proceeding to crash and burn on my design related questions. I’m always worried that the questions I ask might not bring out the particular strengths of a candidate, so I try to give people an opened ended chance to tell me what they bring to the table. This clown gave me a spiel about how he did poorly on the interview questions because they were skewed towards a developer perspective and he was an architect. All rightie then.
2nd Fastest way to blow an interview with me
I’m too lazy to change it, so I’m more or less stuck with an attacking Tie Fighter as my cellphone ring. Last year I was interviewing with a little consulting firm in Austin when my phone rang. One of the interviewer (about my age) had no idea what the sound was. I just couldn’t imaging working in a development shop with people that can’t quote Star Wars. It’s just plain wrong. Like using an interface without prefacing the name with “I” wrong.
3rd Fastest way to blow an interview with me
The same interview from above included a pop quiz that included a question on basic CSS mechanics. Um, google? If you’re actually asking me that, what the heck does this position actually pay?
4th Fastest way to blow an interview with me
So, Jeremy, our architect is concerned that you won’t be happy just writing code and not doing any design. How do you feel about that? Um, bye?
5th Fastest way to blow an interview with me
From a single shop, in rapid order:
- Our architect builds the framework, we just use it
- Them: We want to be database neutral, so we’re using the ODBC provider. Me: That’s a terrible idea! You’re not using stored procedures then are you? Them (looking annoyed): Of course we’re using stored procedures for all data access.
- We’re asking all employees to work 48 hours a week until we ship next spring — and everybody in the room had the bleary-eyed look that coders get from too many hours and too much caffeine
6th Fastest way to blow an interview with me
Steve & I: So, we’d really like to have a tester with strong test automation skills. What is your experience in this area?
Him: I don’t think test automation is very important
7th Fastest way to blow an interview with me
We have our own proprietary Agile process (why the hell do companies insist on trying this line of mularkey) that’s based on RUP. We have our Inception phase, then our Elaboration phase, then…
