tech talk

Zen of Office Politics

posted Wed Sep 26 21:29:25 +0000 2007 - permalink

Office politics are tough enough, but sometimes leading a talented group of smart people into success can be especially mentally and emotionally taxing. Here's some do's and don't's.

Do manage things that have visibility. For example that ticket system. Some of those really old tickets have probably already been closed by recent revs. Go through and pick them off. They make not only you, but your team look good to upper management. Be sure to give kudos where they are due.

Don't refer to your underlings as such. Ever. When you are constantly giving kudos to others, sometimes it feels good to flex your leadership position. Don't. Ever. Do. It. If you need a pat on the back, go to your boss' office and politely request one.

Do build consensus. If you can't convince your teammates you are right, how can you be so sure you are?

Don't make arbitrary calls. There's a difference between tough calls and arbitrary ones -- the tough ones are when your team looks at you to make a decision because there are at least two legitimate technical paths to the same goal. The arbitrary ones are when you tell your boss about a technical decision you haven't discussed with your team.

Do take your team out after a job well done. When the going gets tough, the tough go get dinner and a drink after a job well done, on either you or the company.

Dealing with Turnover

posted Wed Jun 06 21:36:46 +0000 2007 - permalink

It's bound to happen. People move on, or perhaps a decision has been made to move them on. Regardless, it can a deep impact on the moral and work of a team.

What generally occurs when a new application / project / widget is developed is that the person who developed it ends up maintaining it. This can mean that losing your most prolific developers means that you lose the know-how across multiple applications. It can be worse losing those rockstar developers who see problems and self-directedly fix them on their own, developing new processes or apps: suddenly you realize there are things there you may never have even known about, or were told casually in a hallway conversation.

It can be difficult to combat this in a busy environment, especially if the staff is skinny (i.e., not enough developers). But in general, if you have a ticket system (and you do have a ticket system, don't you?) try to get a feel for people's comfort level in sharing the maintenance and assign tickets in a round robin fashion (for particularly troublesome or sore spots in your codebase, you'll probably want to assign them to yourself first to ensure the skill level required and possibly to do some cleaning or subdivision of tasks).

If turnover occurs in the middle of a project, you'll need to assess schedule impact immediately (you have a schedule, don't you?), and negotiate the boundaries of features-to-deadlines. You don't want to turn someone leaving in the middle of a project into a full blown exodus, so handle this calmly, carefully, and deliberately -- everyone on the team will be smelling long hours coming down the pipe, so don't fulfill their worst expectations if you can help it. In addition, I'd recommend planning on bringing someone on after the project is almost done; they can be brought up to speed as you enter the deployment / maintenance phase, easing the burden on the rest of the team without distracting from the core development push.

Turnover is tough, but it's a natural part of any team and should be anticipated (it's going to happen at some point!) and couched in the best possible light when it happens -- people's minds will be necessarily elsewhere when they get set to leave, so be sure to give them a little extra prodding and code reviews before they take off. It'll help you understand the subsystems they worked on, and keep them focused on generating those precious wiki docs you'll need after they're gone.

Interviews

posted Tue May 22 17:40:04 +0000 2007 - permalink

Interviews are such a critical time for a team. A wrong move can seriously damage your teamwork and sap resources. I don't really subscribe to the riddles train of thought, so here's some of the core knowledge I'd expect developers at any position to know. Here's some sample questions from the last time I had to interview someone.

General Theory. Name one thing you'd change about any programming language. This will give you a good idea about their general attitude, and on the other hand may tip off someone that doesn't really understand languages.

SQL. What's the difference between an inner and outer join? SQL is such a necessary component of anyone's resume, don't just assume that it's there -- ask.

OOP. Give an example of polymorphism; give an example of inheritance; name two adjectives to describe encapsulation and explain what they mean (looking for 'protected', 'public', or 'private'). If an applicant doesn't understand these concepts, there's no way I'm going to allow them near my code. These are fundamental concepts; even extremely junior developers straight out of college should be able to answer these no problem.

Ajax. Describe a good use of Ajax vs. a bad one. If you use it, you don't want someone new abusing it -- and the correct answer to this question may vary depending on your philosophy and/or implementation.

SVN. What is a branch and when do you use one? Anyone other than an extremely junior developer should be able to nail this.

I usually have a very small coding exercise, like: Write a function to determine a substring of a string using only functions you create which returns the index of the starting location if found or -1 if not (bonus points if they ask if it wraps!). Yes, it's easy, but remember they are under the gun and are probably nervous -- and you really just want to see how their brain works.

Here's Joel on interviewing, and some Microsoft sample questions.

The Art of Outside Negotiation

posted Wed May 16 23:30:19 +0000 2007 - permalink

There are two primary forms of negotiation when operating a team: inside your team, and with the outside world. When dealing with the needs of your customers and the feedback of other internal departments or the management team (aka, Outside World), you need to be patient yet firm, tactical, prepared -- and don't forget to keep your sense of humor. (The following is mostly for internal dealings (I may follow up with a consulting team lead's point of view shortly, but most of the same still apply in one form or another)).

Patient yet firm. People are just as busy as you are, and may be on the road. If they are on the road, don't rely on email alone. Call them with a gentle reminder -- they actually will appreciate it if you give them a heads up. At the same time, you need to keep your team's momentum moving forward, and waiting on decisions that could affect your system's design, implementation, or deployment can be excruciating, so sitting down and talking with road warriors before they go on the road and setting an expectation on how best to remind them (and how often) can be a good approach to letting them know you are serious, but letting them set the bar.

Tactical. Know your outside personnel. This includes team leads from other software teams and in other departments. Know who has who's ear, and who can audit your ideas before you present them. This isn't meant to circumvent anyone, because you should be acting in the best interest of your customer (first and foremost) and your team. As a software development team lead, you have a special insight into how the company operates, and your ideas may be outside the box for the company you work at -- you need to make sure you can be successful, but also audited.

Prepared. Nothing beats a well formed argument backed by a presentation (except maybe a tight schedule). You need to have hard facts to back yourself up. You need to understand the company goals (especially when talking to high level folks). And visuals help... even bad screenshots cut out and taped to butcher paper.

Don't forget to smile. Many people's immediate reaction to the 'tech guy' is one of someone who is a hardass, nitpicking, lawyer-type. Break them down early with a smile -- it'll help set the tone, set the sales people at ease, and loosen you up. Promise.

Review: Leading at a Higher Level

posted Wed May 16 01:53:22 +0000 2007 - permalink

Ken Blanchard's Leading at a Higher Level is a great work for leaders and aspiring leaders at all levels. While some of the beginning sections are better suited to decision makers at a higher level than a team lead (such as creating vision and creating mission statements), the overall theme of the book is how to adapt to the leadership needs of your staff.

Understanding the development needs of your team, how they learn, and at which point to switch from a decision maker to a delegator to a coach can help not only unify your team, but get the most out of everyone. Changing requirements, stress, working late, and dealing with real time customer issues can create issues and conflicts with your team. I highly recommend this book for team leads that are looking for inspiration to take yourself to the next level and get the most of your (probably limited) resources -- just feel free to skim ahead to the parts about how to treat your people right.

Anticipate, Plan, Execute

posted Tue May 08 16:57:11 +0000 2007 - permalink

One issue we always seem to face in software development is our own fantasy about The Phantom Specification. This usually involves one or more of the following symptoms: claims of being unable to proceed without the specification, an inability to foresee any changes to the codebase, nervous laughter, and/or trying to hide out in a corner of the office away from everyone else (at least more than normal).

Specifications are generally hard to come by and are tough to lock down. I've heard ideas on obtaining and locking down specs from getting all stakeholders to sign a spec (mostly, I believe, in order to get them to read it), to spending several months attempting to nitpick every last detail via committee. There's the opposite idea as well in the agile software movement's Matrix-style believe that there is no spec. While the agile software movement has a lot of cache, in my experience somewhere in the middle lies the truth.

Which brings me to the point. Senior developers on any team need to be consistently anticipating, planning, and executing to fill in the gaps left by Phantom Specifications. Anticipate company changes, and begin planning early to meet those changes so that you can effectively set priorities. Currently, I'm working without a specification. But I have been able to anticipate and plan around our new products, allowing us to make the proper codebase overhauls to support three new products. By the time I receive the three specifications, we'll be all set to cross our t's and dot the i's so that with any luck we'll be able to deliver on time.

Six Tipping Points to Project Success

posted Tue May 01 21:09:04 +0000 2007 - permalink

From a tip from the Harvard Business Review's IdeaCast come some tips on project wrangling, and I'll try to wrangle them into ways software development team leads can use them for project guidance.

• KISS. Keep it simple when you are starting a project out. When you are drafting that Software Requirements Specification, make the language mitigates those lofty goals and is clear. Lots of SRS' like to add in whimsical little statements of purpose that read like mission statements. As Computer and Information Science grads, we take great pride in our ability to generate specificity (and thus inherent complexity) in our definitions. Quite the opposite, we need to learn when starting a project to start simple and allow the complexity (which we all know is there) develop naturally which should help lead to more elegant systems and a better understanding by the stakeholders involved.
• Challenge assumptions. Stakeholders and development teams can sit in a meeting for several hours believing everyone in the room is talking about the same thing -- then suddenly realize they actually aren't and have to start over. Challenge assumptions early in any project by coming up with with small, quick definitions to share.
• Speak the same language. The definitions themselves are a way to build the system around the language being used by the stakeholder, and eases the technical to non-technical language barrier.
• Discuss resources early. This should be natural, but also be thinking about schedule, your other projects, and maintenance plans after deployment.
• Continuously monitor performance. How else can you benchmark yourself to improve on later?
• Develop execution ability. This may be inherent in your hiring decisions and continuing education, but it also depends on the ability to elicit buy-in and motivate teams to deliver.

Review: The Last Link

posted Mon Apr 30 17:53:29 +0000 2007 - permalink

As I've mentioned before, it can be a great boon to your organization if the software development team leads have an understanding of the business. It helps when negotiating schedules, understanding the development cycle and maintenance requirements, and the actual needs of your customers. In an effort to better understand how to close my own personal business-speak gap, I turned to Gregg Crawford's The Last Link.

The book itself is decidedly meta. With subtitles like 'The way to close the gap between your corporate strategy and the results you seek is to execute effectively' (for chapter 3), I find some of the content a little hard to swallow. For example, how do you identify key 'decision makers' and the 'strategy to connect them'? I guess you just 'do' because the realities of the process are buried in an ever-murkier digression of marketing speak that would at best belong on the book's jacket rather than anywhere within the text itself.

For all of the professional programmer's loathing of market- speak, there are upsides. One very good chapter is chapter 4, which points out that we need to not only look at results but also at processes, including things like days it takes to close a sale and average number of days of each deal per stage. This also means that development teams will probably have to provide means for managers to report on these contexts, but it also validates a lot of what engineers do to close our own gaps in delivering useful software on time and under budget (for extra credit, sprinkle in some of the 6- sigma lingo about self-correcting-processes embedded deep into your processes). The best part, even if I was in sales, is at the end where he has little walkthroughs -- the only real illumination of the entire text.

If anything, this book actively demonstrates exactly what it purports to fix -- there is a distinct gap between the overall company strategy and the implementation and execution of that strategy. Ultimately, if you work on a software team that builds a company's internal tools, you understand where the tires hit the pavement and you need to make sure to provide input to the leadership team as to how best to implement, if not execute, the pieces of the strategy that require customized software and reporting. Coming to internal tools only after sales has attempted to rollout a new strategy only exacerbates the intracompany problems, and careens any hope of successful sales execution toward failure.

Software Maintenance

posted Sat Apr 28 19:35:53 +0000 2007 - permalink

Software maintenance can be a tricky piece of scheduling. On the one hand, many managers would prefer to shove it under the rug and pretend that it doesn't exist. On the other hand, they want their changes to the existing codebase now. But ultimately there will need to be some scheduled maintenance, and generally waiting for 'bugs that look the same' to crop up and then fix them all at once is a tactic that although it looks good on paper, isn't all that great in practice (if it affects a customer, it should probably be fixed immediately).

In the first part on estimation, I advocate a 50% efficiency on new software development at 4 coding hours per day, partially due to maintenance (and meetings, code reviews, specification gathering, QA, documentation, etc).

One thing that is crucial for team leads is to try to understand the business environment you are working in, and work maintenance into the schedule instead of shoving it under the rug. For example, is it seasonal (do your people use your software at certain times of the year)? Is maintenance by contract (and if so who else needs to be involved when a maintenance request comes in)? When will the first wave of users hit the software (when they do, you will want to have time in the schedule for possible maintenance)?

Internally, along the same vein, are the setting the maintenance priorities. This can be a bit more tricky, but being able to have a company wide understanding of what priorities mean via definition can be an invaluable tool in setting expectations. For example, at my office, if a bug hits more than one customer we are expected to try to fix the bug within the next 24 hours. If it affects one customer (i.e., something special with their software configuration settings), we will try to fix it within 72 hours (and possibly have an engineer call the customer and walk through it because I believe that if one customer has an anomaly, odds are there are other customers out there that have the problem but haven't spoken up). Internal requests, while generally good ideas, are placed in the queue and fixed when we have time. All bugs and feature requests go into the bug tracking system (you have a bug tracking system don't you?)

As a team lead, you must mitigate all of these issues to ensure your team's success and provide your customers with the best possible experience. In general, your communication with the staff at your company, including escalation plans, and your understanding of your company's business model will put you a long way towards success.

Launching Software Projects

posted Wed Apr 25 18:04:09 +0000 2007 - permalink

Launching software is rarely fire and forget. Even if you have another team designated to cover the maintenance of a project, odds are you will be fielding questions if that team was not an integral part of the development process. And sometimes software launches can take several months with a phased rollout. In a small development team, this is something you should at least be aware of if not trying to channel. (I mean, you are trying to keep to your schedule, right?)

What does this mean for your schedule and estimation? Generally, any project that makes a significant impact on your customers will probably have to be either a phased launch or well communicated. The definition of 'significant impact' will probably need to be researched in terms of raw numbers (and I mean SQL here), surveys (hopefully someone did these before you started the project), and general hallway consensus.

I like the Gang of Four's idea of 'smells' around a problem, and in this case let's look at some project launch smells. In my opinion, these are the common ones:

• Money. If it smells like it may make customers go somewhere else, or scare off potentials, by making it more difficult to deal with your company, expect a launch delay if research has not been done. This generally means you need to get a survey (how likely are they to move?) and talk to accounting to find out numbers on how big of an impact this may have and match that to some of your own queries. Odds are, development and QA may be complete but management may not decide to launch the project for several months.
• Manufacturing/Customer Relationship Process. This is extremely dangerous for launch dates. You have a whole host of issues, including manufacturing, shipping, your internal tools, possibly accounting (check with your controller to make sure) and messaging these changes to the end user. I highly recommend meeting on this early and often. Usually in growing companies, this will happen often which leads to disassociated subsystems. Look for places where you can consolidate subsystems and processes to save yourself time to make sure this new process also works for your customers.
• Online Process. This is generally low threat level (unless it's a complete website framework overhaul like we did late last year). If a process changes more than a few clicks, you'll want some help text for your existing customers.

Knowing the launch dates is an important part of leading the development process forward because it dictates when your maintenance cycle is going to occur -- and knowing when the likely times that priority one bugs are going to be submitted and interrupt your work is critical to ensuring you and your team have the proper time to work on your projects.

Estimating Part II: QA

posted Mon Apr 23 17:15:37 +0000 2007 - permalink

Estimating the quality assurance time on a software project is a tricky business. Despite hallway meetings, iterative demos, and meetings to try and nail down exactly what a project is supposed to be, a little padding can go a long way. So let's get two key points down in estimating how long quality assurance is going to take in a small team environment without dedicated quality assurance engineers.

First, we have the developer working on the project setup the initial testing document. (Someone else will actually be doing the testing -- sales, customer service, etc). Yes, this can eat up up to several days of developer time. But the person working on a project is most likely to identify corner cases that an outside case writer might not see. (It's another thing entirely if you have qualified QA engineers on staff; for small teams, this usually isn't an option.) Also note that you may need to proof these documents before assigning them to another staff member (or sending to your project manager).

Second, in an effort to provide some flexibility (aka Agility), QA has to be scoped based on a variety of factors: how large the project is in terms of moving parts, how many of those moving parts have various inputs (for example, a recent project needed approval from three department heads, meaning that we will probably get the changes after coding is complete), and whether or not refactoring has been attempted in other subsystems (which means they have to be QA'd again as well).

This brings up a difficult proposition. QA estimation time can be used for insulation to remain agile on a project that requires high flexibility, but then again it shouldn't because then you're breaking your time trials and not collecting accurate data on how your team is really performing (see my previous post), which in the long run will hurt your team (especially when marketing is already ramping up their engines on your hot new product line).

Team harmonics play into this at critical points. First, your team has to believe that the original estimate can be completed. Your judgement, whether via multiplier or some other quantification of the dynamics of the project, will be critical in determining the QA estimation period in a small team, and as changes come in on a dynamic project, you'll need to judiciously carefully allocate time that bleeds into QA. Your relationship with your project manager will be clutch when this occurs.

And don't forget -- a 4 hour per day work schedule estimation on projects will allow you additional flexibility to protect people working on a critical project from some maintenance tasks to allow them to hit schedule. It is extremely difficult, but separating out the hours worked on non-estimated items can give you great insight into your next project.

An estimate by any other name...

posted Fri Apr 20 00:21:21 +0000 2007 - permalink

We've been out various estimation techniques for about the last 6 to 8 months. T-shirt sizing (large project, medium project, small project) is a good way to get a project onto the schedule initially (for example, next year we might pencil in one large project, two mediums, and an assortment of small ones). But ultimately, one needs the details.

Given that we have a small team, we estimate that approximately 4 hours a day will be spent coding on any particular project (since we all have to do maintenance, estimation, project post mortems, scheduling, politiking, and documentation). This will probably vary by team size and if you are large enough, the type of team and how many teams you have. Estimation is almost always tackled in pairs, because a lot of the system design is done during estimation.

The general idea when doing the actual estimation is to break down the project into discrete parts and estimate each individually with a worst case estimate, expected estimate, and the best case scenario. This should include rapid debug cycles, but the actual quality assurance piece should be estimated separately. Because we have to break down into discrete elements, if it's a large project we may bring together the entire team to help perform the estimation.

Now that we have raw numbers (worst/expected/best) for the project, we can begin to play with our numbers. Our current method is to take three times the expected, add in the best and worst, and divide by 5 (so (3E+w+B)/5). This is then divided by the expected number of project work hours per day to get the actual number of days the project should take (we always take the ceiling of this value). For multiple developers, divide this number by the number of developers and take the ceiling of that too -- since you've already broken the project down, handing off discrete sections to work on shouldn't be terribly difficult.

One thing it takes a team a little getting used to is the fact that estimation and scheduling is meant to make you better. It's your time trial information as a sprinter (or long distance runner as the case may be). Obviously if you can't hit your estimates and you are unwilling to adapt your estimation or work habits, you probably will need to find a new avenue of employment soon. But if you are constantly improving at estimating and hitting schedules, management should reward positive outcomes and fight for improvement on the negatives. Keeping a track record is the first step to success.

Tomorrow I'll talk a little more about the QA estimation process.

Lookup tables and gettext

posted Wed Apr 18 21:47:26 +0000 2007 - permalink

A first pass look seems to indicate that PHP's built-in gettext functionality may solve the problem for our embedded strings, and that 'lookup tables' will help with any database text (one lingering question for the database lookup tables for me, however, is maintenance).

In addition to the text problem, our reports require energy calculations which means data conversion as well. Any decorator that runs on top of all of the reports will need to pepper them with the appropriate metric/American values. This looks increasingly difficult due to inheritance, because rather than having a single method to get a sensor's performance, these methods will need to be broken down into smaller atomic pieces so the decorator can discern what needs to be overridden.

Another option besides the decorator, however, might be to provide a messaging class that can be cast back and forth. This allows the superstructure to remain intact (which, organizationally, makes it easy to find bugs and read as a developer) and essentially cast the message on display depending on the user's preference (or where they are located).

A tale of a complicated report

posted Tue Apr 17 22:54:00 +0000 2007 - permalink

At my office we're currently in the process of a multi-pronged attack on one of our most complicated systems - a report engine that has to factor in multiple report types, the type of user requesting the report, and now... internationalization. In addition, we're revamping a semi-failed report we developed last year for the commercial sector. I've never done internationalization before, so I'm going to spend some time writing about it.

We currently have a half-implemented factory pattern for generating the reports themselves, and now we're going to try to lay a decorator over it. This will no doubt be a major undertaking and be taking most of my time until August 1s as these report engines comprise most of our 51,000 lines of code. I'm also going to spend some time writing about some of the crucial design decisions we make to hit our deadline.

OSCON results

posted Tue Aug 08 00:14:48 +0000 2006 - permalink

Some of the best information I got out of OSCON was talking to people and getting to know some new tools.

PHP
APD - Watch your function calls scroll by.
APC - Alternative PHP cache.

System Administration
Scalix - Looks to be a very cool Exchange server emulator.
Nagios - Monitor everything, and report on it.

Other Stuff
Callgrind and KCacheGrind - See pretty pictures of your application's calls to help profile.

OSCON In Portland!

posted Thu Jul 20 22:37:18 +0000 2006 - permalink

I'll be manning the Free Software Foundation's booth at OSCON on Wednesday and Thursday, July 26th and 27th. Stop by and say hi! Entry to the exhibit area is free! See here.

The Round Table Development Model

posted Wed Dec 07 08:37:12 +0000 2005 - permalink

Having custom software built is expensive. There are multiple phases of development to account for, some quality assurance, let alone coming up with an initial specification. But it is, to a large extent, customized to your needs. If the contractor is worth their weight in code, they should be checking in often, making sure your business processes are met, and things are streamlined. And if you have input to how it works, you do save some time and effort in training.

But buying software off the shelf can be expensive too -- licensing, configuration, compatibility, setup, and training. And how quickly do they respond to you when something goes wrong let alone crashes, and how much do you pay for that responsiveness? I say that more options doesn't necessarily mean more functionality because when you look at all the options present in an off-the-shelf piece of software, it may be able to do everything you ask it -- but are you utilizing 100% of those options? How many features did you really buy, and how many are left unknown? Not that I'm saying that off the shelf software can't meet your needs -- it certainly can -- but in my experience there is a real benefit to face time and process analysis for each customer.

So, I have this idea: Software as investment. (Pure realists will now say that this is already how it works. But hear me out.)

Right now the tools exist such that small teams can build and deploy applications quickly. That cuts the cost substantially -- both by negating the Big Consulting Firm overhead but also in keeping the team small. In addition, there are probably others out there who may need the same set of functionality. Why not provide investment rounds in custom applications, allowing the 'investors' input not just in the design and specification phase, but throughout the development and deployment process?

By spreading the cost over several buyers, each gets input into the process of development, and receives the benefits at a reduced cost. This, however, has to be carefully managed, and someone with a proven track record would need to be trusted with assessing the viability of the project, overseeing and assessing the input from the investors, and keeping the entire project moving forward to delivery.

But I've been giving it thought, and I believe I have some additional ideas to overcome the obstacles. If you have ideas or input, I'd love to hear them as well.

The Real Agility

posted Mon Nov 28 04:31:04 +0000 2005 - permalink

The Manifesto for Agile Software Development seems to turn things on its head. But does it really? After a long string of 'solve-all' paradigms for software development (SOA being the newest), it seems that true agility lies with the small able team, the quality of their interactions with the client and the real ability to respond to change.

And it doesn't mean that it's process free. For me and my cohorts at Naked Developers, we have our own methods for keeping in touch, posting updates, and our methods of development probably don't match other teams. But it does follow the principles of agile development. And it is a reflexive process of constant improvement.

Requirements do change. Usually people don't realize their user interface or data needs until they're knee deep in them. And agility isn't inherent in the software itself because more options doesn't always equal more functionality. The agility is in the process that brings it to fruition to meet your needs in a framework that gives developers the ability to meet those changing requirements.

And building that framework takes experience, fast learning, and clear lines of communication.