people

I was recently asked about what separates my company from others I have worked in the past. What immediately came to mind was the relationship with my team, the work we do, and the sheer talent. Those elements alone still make me get up in the morning. But, over a cold beer, something else struck with me. My company has no routine and I love it. Let me Google that for youYes, this may set you back initially. Routine typically has to do with schedules or habits. But, what I am referring to is very much about our culture. We're a newer company that is still applying polish to our offerings

Estimations suck. Seriously. To do estimations properly, it requires significant analysis and a sound grip on the full project scope. It's hard. There are always unknown complexities that creep up. Estimations set expectations and impose risk when complexity is not identified. Covering RiskThere are a couple approaches people use to balance estimates with risk. The fixed percentage model just adds a near arbitrary percent on top of a given estimate for known complexity. While this is fine, it doesn't excuse a lack of effort to try to determine what the estimates should be. Another is

Recently, it hit me that there are actually benefits to having a short term memory. I don't think this is broadly applicable. In fact, I think there are more instances in which you do not want to have a short term memory. Allow me to explain... Mistakes and GrowthI'm a firm believer in learning experiences. I believe people need to be afforded opportunities to learn. These often come at the cost of making mistakes. In essence, people should be granted the opportunities to make mistakes, learn, and then grow. As an example, I recently made a decision at work that caused an issue. My team was

Companies are very bottom line focused. Even after a high level scope of work is determined, the most appealing bids often are on the lower end. Even if some form of a deliverable can be achieved in a given number of hours, it often does not yield the correct one. Smarter bids allocate more time for damage control, error correction, and proper testing. For low bids, especially really low ones, one has to wonder what part of the product suffers. Most places I have worked have emphasized ethics and client success over the written contract. And, honestly, this tenet is part of my moral fiber. I

Rands' recent blog post Busy is an Addiction struck a chord with me. It's made me rethink many aspects of my day-to-day routine. Work Smarter, Not Harder It's so easy to say, I'm busy. In reality, I should be working smarter, not harder. Busy is as much of a state of mind, as it is the items on your plate. It's a routine, a lifestyle, and a shitty excuse. If you fall into the busy pattern, I personally believe it's easier to make mistakes. Your pace is more frantic, your getting pulled in thirty different directions, and you really don't have the time needed to pay attention to what your doing

Projects are risky. Specifications are nearly impossible to define on most projects due to technical or communication gaps. This is the age old challenge many people fight. One popular solution for unclear specs is the fail fast methodology. It's founded on brief iterations that lack polish, frequent tests by a client and an over abundance of communication. This strategy is common for rapid prototyping and is effective for clients that can get their hands on something visually. All too often we fall into the trap of quality. Quality, to me, is only a metric of a final deliverable. It should

Bad projects are toxic. While most staff within a company focus on the bottom line, the bottom line is no guarantee of project success. It's impossible to look in your crystal ball and make this call before a project begins. Hindsight is 20/20, right? This could be due to any number of different factors. Some I have seen include: clashing personality between teams, a lack of participation on behalf of the client, unclear expectations of roles and responsibilities, client changes the requirements throughout the project, client cannot provide the clarity of the requirements, etc.When things

At the heart of Agile is flexibility. This is designed into sprints that are intended to account for changes rolled into subsequent sprints.But, think of an overall backlog. A high level estimation will yield a given number of sprints. This structure actually is not very flexible at all. Unless, of course, each sprint has time allocated for reviewing, testing, and bug fixing. This is a slippery slope; a more substantial change can really throw off a sprint. So, how do you address the issue of quality?I have recently been reading a lot about corporations paying others to hunt bugs in their

Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer. Let's be clear though. Every project has risks. Every project has some complexity behind it. What this means is that there is a dark art to the design decisions made by the developer. I've never seen a client accurately define what content types or modules need to be installed. Again, if they were that educated about what needed to be done, they wouldn't be paying you to do it. The developer must learn

Peter Nixey describes good developers as both technology proficient and hard working in his blog post. His concept of "simplicity" is worth noting. I highly encourage developers to create code that limits complexity. But, there is an even more important aspect of complexity: usability.Simplicity and excellence are most reliably attained by starting with something, anything, that gets the job done and reworking back from that point.Enter the noob. Every project should have someone in this role. Technologically detached. Familiar with project goals, but does not look at one line of code. No