Owocki dot com

Eliminate Inefficiency with Automation

— This post is part of a series of ongoing tips on lessons learned & experiences I’ve had as the lead developer of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I’d wish I’d known as a lead developer at Techstars. —

I spend a lot of time building and reading reports. I also spent a lot of time shuffling files around, and formatting data.

If you’re like me, you probably also spend a great deal of time doing simple, mindless, monotonous tasks like normalizing data, working with log files, or transferring files from one development region to another. While they are completely necessary, these simple mindless tasks take a ~long~ time.

One of my favorite things to do when executing these types of tasks is to figure out where I can eliminate the inefficiencies in my process. Since I’m running a startup, and am not subject to the process of some large bureaucracy, the power (and responsibility) to optimize time-inefficient tasks falls with me.

What types of tasks I automate
Most of the time, this process starts with a task that I have to do twice. The first time I do it, I groan, but I suck it up and do it the brute force way. The second time, I look for a pattern to emerge, and if one exists, I write a script to do the bulk of the work for me.

Part of the fun with this approach is that, while you are performing a mindless task, you can let your mind wander about the ways you could be improving your workflow.

Tools of the trade
If you aren’t familiar with shell scripting, you probably should be. If you’re on the LAMP stack, get to know your cron tab. Also, QTP is a great tool for Windows UI automation.

Some Use Cases
Here are a few examples of time-saving scripts I’ve written. In the past, I’ve written scripts that
- Build Regions.
- Normalize Data into JSON, MySQL, or XML formats.
- Build cached versions of my codebase.
- Find Database Integrity issues, correct them, and notify me so I can investigate deeper.
- Backup my codebase and database.
- Comb my log files for a search query.
- Email daily, weekly, and monthly statistics reports to my team.

Bottom Line
It’s a best-practice to always be looking for ways to optimize your processes.

How much time could you save if you automated your repetitive tasks today?

First Time Startup CTO Tips #3 - Develop Code Standards (and Stick To Them)

— This post is part of a series of ongoing tips on lessons learned & experiences I’ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I’d wish I’d known as a lead developer at Techstars. —

One of the biggest differences between writing code at school and writing code today has been the need to work with, interpret, modify and/or rewrite code that my teammates have implemented.

It’s been a humbling experience, to say the least.

Everyone has their own habits, their own rhythms, and their own way of thinking about code patterns & implementations.

And when you don’t draw a line in the sand upfront, things can get messy, really, really quick.

So, one of the biggest boons to team morale (not to mention, my sanity), in the last 12 months, was when the team, together, developed coding standards to adhere to.

And the biggest boon was when we actually started following them.

Here are the standards that, in my experience, have been the most helpful in keeping both team morale & team sanity up:

- Introduce indentation standards. It’ really simple. Just nest if statements, loops, and function declarations with tab indents. It allows my eyes to scan code 3x faster than when for loops, if statements, and methods aren’t indented. And that’s just fantastic.

- Comment every method you create. We list the preconditions, postconditions, return variables, and input variables for each method in our code base. We have a standard comment template that is already formatted to receive these values. Here’s what it looks like:

/*********************************************************/
// - Input vars:
// - Preconditions:
// - Postconditions:
// - Returns:
// - Comments:
// -
// -
function Name($InputA,$InputB,$InputC,...) {
//Method code goes here
}


- Introduce variable & method naming standards. Simple standards around how you name your variables can help code readability a lot. Start with simple things like what to do with individual words in variable names ($AVar or $avar?), whitespace ($A_Var or $AVar?), upper & lower limits on length.

- Make code granular & reusable. This is another one that sounds like a no-brainer, but in practice sometimes it’s a hard one to stick to. There’s an entire body of academic research on why your code should be de-coupled and cohesive.

- Find & follow a standard design pattern. The nice thing about design patterns is that someone has thought out the common issues and written rules for you to follow. For me, Model-View-Controller has made my life so much easier. If you’re writing a web app, that’s probably the main design pattern you’ll want to familiar with.

- Peer architect. I like the practice of talking over solutions with teammates before I implement them. It’s a useful way to lay out your design theory and test your assumptions, before you actually write a lick of code

There you have it. I’d be interested in hearing what standards your team has developed, and how you enforce them / make sure you stick with them.

Oh, and if you want to follow musings of the awesome development team I work with, please do so here: @nleach @aycaaksu @maxstoller @maxmeyers, and @zeve .

First Time Startup CTO Tips #2 - Develop a rhythm

— This post is part of a series of ongoing tips on lessons learned & experiences I’ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer-focused startups, they ring true elsewhere too. For a full list of these tips, see 10 things I’d wish I’d known as a lead developer at Techstars. —

One of the most crucial things our team did over the last year was adhere to a rhymic development schedule:

Every Monday, we release code from our development region, to our production region. For the rest of the week, we analyze our business requirements, design accordingly, and implement new features in our development region.

This allows us draw a line in the sand when it comes to prioritizing features. It allows you set firm targets and deadlines. Abstract questions like “Is feature X more important than feature Y?” become more practical. The conversation becomes: “Can you get both feature X AND feature Y into the release on Monday?” , “No? Ok, how about just feature Y, then?”.

It also allows us to break projects into manageable chunks to iterate on week over week. Iterating, measuring results, and repeat. It’s a fantastic way to stay agile. And staying nimble & agile is the goal for the development team when you’re trying to find the ~right~ product for your market.

On to the details:

What day do you release?
We’ve had a lot of internal debate on what day of the week to release. We chose Monday because it allows us to start fresh and focus on new priorities for the week (Provided there were no issues with the push).

How long should your iteration cycle be?
My team releases weekly. I’ve heard stories of many other startups who release weekly. Some release daily. I’ve found that the overhead involved with pushing code live is too great when pushing on a daily schedule. Anything over a week, and I’m concerned that we aren’t iterating fast enough.

How much effort do you contribute to QA?
Quality assurance is a major concern when you’re developing a consumer app. In my opinion, it’s best to design multiple levels of QA into your process, executed throughout the week. A suite of unit tests helps to catch bugs introduced throughout the course of a week. Next, each team member is expected to troubleshoot and certify their own features by release time. We also do a weekly QA session in which we catch bugs before we do the push.

Do you follow any ‘development methodologies‘?
No. For now, we’re wary of adding too much process too early in our company. Though, we do regularly study our process and evolve it as needed. Agile looks like an interesting option for the future. As does Lean Programming.

All in all, your release rhythm will probably depend a lot on your product, market, and most importantly, your team. When making decisions about your development rhythm, start with the low hanging fruit, like ‘How long do we want our cycles to be?’, and ‘What time of the day/week/month/quarter do we want to release?’, and move on from there.

Oh, and don’t forget to have a fun through the process. One of my favorite parts of being in a small team are the fun little events (LAN parties, dinners, lunches, etc..) that we schedule to celebrate a big release.