Justin Carmony » Software Development

Joining a Startup – The Advantages

Justin Carmony — Thu, 21 Jan 2010 06:50:36 +0000

While going through my backlog of my RSS feeds. I stumbled on Keith Casey’s post on Joining a Startup. He wrote it as a “reality check” for people who are considering joining a startup as a developer. Here is a snip-it:

First, everyone does everything. Check your ego at the door. In the first startup I was with, I was in charge of adding reporting to the eCommerce application and taking the garbage out. Was it an effective use of my time? Not at all. Did it have to be done? Yes. Did we have the money to hire someone else? Nope. If your startup is renting office space, you probably won’t have to worry about this… but who signs for packages? Who re-orders coffee? On the flip side, you could be the one taking technical questions at the next investor pitch or invited to the big customer Christmas party.

I thought he hit the nail on the head with the article. Over the last few years I’ve worked with three startups, one of which was successfully bought by a large corporation. The other two have successfully gained some good revenue, but are still in the “Looking for More Money” phase, and I continue to do work for them on a contractual basis.

My only concern was that at the end of the article, he only mentions that he is still okay with working for a startup. He didn’t mention some of the biggest “perks” I consider working for a startup. So here are some of the items that, if you can handle the “draw backs”, are some great things. These are not “guaranteed”, as each startup is different, but typically you’ll find some of these.

Accelerated Learning – I’ve felt that I’ve learned at such a faster rate while working in a startup. In large development teams, you typically work on very specific things. Your team only works on one part of a larger project or product. However, with the startup, you typically have to do a lot more varied work. At Ambient, the company that was sold, I was a junior developer of a company of three developers. Here is the list of some of stuff I did in roughly one year:
- Company Website
- All Web Services
- All Web Designs
- Website Demos & Prototypes
- Data Mining Services
- Executive Dashboard
- Sales & Inventory Reporting Website
- Customizable Online DVD Rental System
Not only did I work almost exclusively on these projects, they integrated with the pieces the other two developers worked on. For three developers, we cranked out a lot of great software. Since I was the junior developer, when ever we had a tech support issue that was a little too complicated for our two tech support guys, I had to diagnose and solve a lot of complicated issues. I got experience with VPNs, LDAP and Active Directory, very large databases (100,000,000+ rows), VNC & RDP, and automated deployments across thousands of remote locations, to name a few.

If you enjoy getting your hands on a lot of different technologies, and do a lot more than in a normal company, you can really learn a lot at a startup.
Less Politics, More Work – While I know this doesn’t apply to all startups, the ones I’ve worked in seem to have a lot less politics than other companies. I believe its because, first of all, there are less people to have politics with. Second, there is way to much work to get done to spend time on playing politics. Everyone seems to just be focused on getting work done.
More Input, More Direction – While working in a startup, I’ve found that I have a lot more say in how we do things compared to other companies. Creativity isn’t just a bonus, it is a requirement. Many times you are working on an idea, not a detailed specification. Your creativity is required to make the idea fully functional and work properly. I’ve found many times my ideas are implemented, and while looking at the final product, I can see my influences all over the place.
Closer Team, Fewer Annoying Co-workers – Some may think this is a myth, however what I have experienced is startups don’t have time to put up with teams that don’t work well together. For the exception of one guy who was really nice, but a major pain to work with, I’ve enjoyed working with all my co-workers and (I hope they can say the same about me). Typically people who don’t enjoy the fast pace leave after a short while. If there is an employee who doesn’t get along with the others, typically they will go find work elsewhere because the stress of the pace and not getting along well with others compound out of control. Even if they don’t leave on their own, management will usually find some solution, because a team that doesn’t work well together won’t produce the needed products to make a success. Unlike a large corporation, there isn’t anywhere to hide bad workers. If you’re not carrying your own weight, you’re gone.
No Boredom, High Adrenaline - The pace can be stressful, but I found it most of the time exhilarating. There is never, ever a lack of work. Currently for the two startups I’m doing work for, there are years and years worth of work I can do. Sometimes the deadlines can be a killer, but meeting them is very rewarding. Its an awesome feeling when your team of two developers and one project manager create a product that out performs & demolishes competing products from large, well established companies.
High Levels of Satisfaction – I personally feel I get more out of working for a successful startup. Since developers will produce more code and applications than in other companies, there is more to be proud of. If you’re team is really tight, and a few of you create an amazing product, it is an amazing feeling.

So while startups are not for everyone, and they have their drawbacks, I believe certain types of developers can find rewarding work in them. I know I’ve been lucky to work on some excellent products, and I haven’t had an experience (yet) where I’ve gotten burned. Maybe the things I’ve mentioned aren’t as common as I think, but I truly believe startups offer opportunities for developers to really accelerate their learning and excel at rewards jobs.

Data Backups – There Are No Excuses

Justin Carmony — Sun, 19 Apr 2009 00:04:48 +0000

Today I just had the terrible experience of having a database lose data, need to restore, only to not have a recent backup. If you haven’t had this experience before, please, take this serious. My wife was home for lunch as it happened, and she watched as the blood drained from my face. It only took a few seconds for the loss to happen, and immediately I knew exactly what the repercussions where. The immediate second thought that passes through your brain is “Where are my backups?” That is when I realized I didn’t have my nightly backups set up on this server. I quickly checked the file date on the last known backup I had.

13 Days.

It could have been a lot worse, but it was still extremely bad. Those last thirteen days had been record setting days. Emails each day were going around about record new signups, records internal messages sent, etc. Those thirteen had been the best 13 days by far.

If some of you are wondering what had happened, and know me to be very diligent in my backups, I did the one wrong, terrible thing: I made an assumption. I’ve blogged before on how backups have saved me in the past, and how I am almost a fanatic about them. So what the heck happened?

This website was on some hardware that was starting to get overburdened. Then, out of the blue, our traffic exploded and our web server and database server started to grind to a halt. I spent long hours and sleepless nights migrating from these old servers from a terrible host to some new virtual machines. We then discovered our MySQL Database was so intense that the virtual server couldn’t handle the CPU and I/O requirements. Finally, in a last attempt of desperation I moved the Database to a spare box of another company who gave me permission to use it temporarily. That finally worked and allowed us to handle the load on our Database. By the time I finished this, it was about 8 AM in the morning and I went to bed.

I assumed we’d only be on this box for a day or two, so I didn’t setup the backup scripts. However, it gave us more breathing room than we expected, and other issues came up non-db related. The company lending the us the server said we could take our time, so the urgency on ordering our new hardware was pushed off more and more. I had completely forgotten about setting up backups scripts, and we ended up where we are now.

What I’m Changing Personally

I’ve decided to make two changes personally after this experience.

First, there are zero excuses for not having automated backups. Zero, zilch, nada! If a backup should have occurred, there is no excuse for it not to happen.

Secondly, I’m going to pick a day of the month where before I do anything else, I verify that all the backups are working. My father-in-law on the first business day of the month has the habit of doing his business’s billing and other accounting activities. He lets just about nothing stand in the way, and all ways checks his bank accounts and records to make sure everything is in order. I’m going to adopt this same idea, only with servers and data. The first business day of the month I’m going to go through all the servers under my care, verify the backups are working, check error logs, etc. I want to catch the problem before anyone else does.

How To Prevent Data Loss

Here are a few guidelines to make sure you don’t fall victim to data loss.

Select a Backup Schedule & Follow It 100% - I suggest for most websites, a daily backup will work out pretty well. If you have a lot of data that would really stink to lose that changes frequently through the day, you could backup several of the tables hourly.
Back Up To Several Locations – I like my servers to have two hard drives. One for the live data and another for backups. Then, after a backup has been created, I like to sync that backed up data to another server. It is important that if a meteor fell from the sky and hit your data center (or a flood, fire, earthquake), you would have a very recent backup somewhere else.
Verify Your Backups – I can’t stress this enough. After this terrible accident of not having a recent backup, I went and checked all my other website database backups. I found out that one critical database’s backups were broken and not running nightly. You never want to find out this information after you have to restore from a backup. Regularly verify that your backups are being created, and that you can restore from them.

Hopefully this will motivate at least one person in our profession to evaluate their backup strategy and make it better. You don’t ever want to tell a client that you just lost 13 days of their record setting work.

Software Development With Clients In Mind

Justin Carmony — Sat, 31 Jan 2009 17:05:56 +0000

Why does it seem so hard to deliver quality products to clients? Sometimes it feels like clientseither don’t appreciate quality, or they have their priorities all mixed up. To help us understand, here is a wonderful sketch from Monty Python called “The Architect’s Sketch.”

I’ve been searching for awhile for a good example for this subject, and when I saw this sketch, I knew this would be perfect. It outlines two large problems with developing solutions for clients: quality & suitability.

In the sketch (transcript avaiable) each architect presented their solution. One was very well designed with high quality in mind. The second solution was well suited for their needs, but obviously has a sub-par quality. Which brings us to the conclusion, which solution did the developers pick? The poorly designed one of course! Why? Suitability, how well somethings fits, comes before quality for consumers and clients.

These seems rather obvious, but in-fact many developers get caught up in quality and then are totally surprised when their clients aren’t happy. Why? Because as developers we notice and respect quality a great deal more than suitability. However, clients rarely consciously notice quality. Sub-concisely they’ll notice speed, performance, bug-free, etc. However, they don’t really realize it, it is just something they come to expect. If a software solution doesn’t suit their needs as they would like, no matter how high of quality the solution has, clients and consumers will think its poor quality. So how can we deliver a high quality solution that also is suitable for their needs?

Understanding Needs

Before you can meet a need, you must understand it. I think software development education is severely lacking in helping students learn to understand client needs. There is a lot of education on theory, best practices, and technologies like programing languages and database design. However, at the end of the day, these techniques fall under the “quality” category. Don’t get me wrong, all these skills are extremely important and deserve the time and effort they receive. But what about suitability? I don’t care how well a program is designed and coded if at the end of the day it doesn’t suit my needs.

This is what my current boss calls the “get it” gene. There is so much more to software development and design than just under the hood. Like I’ve said before, clients and consumers don’t really care whats under the hood as long as it is working. For them their number one concern is having their needs met. Have you ever received a specification, followed it exactly, only to have your boss or client turn around and say that it won’t work for their needs? It has happened to me, and its extremely frustrating. It feels like such a waste of work many of the times.

Developers who “get it” do more than follow specifications. They can visualize the people who will use it and understand what they need. Specifications are usually just a good outline, and when following it a developer needs to ask himself these questions as he works:

What are the needs of my end-user?
Why are they doing this?
Is this a practical way to accomplish this task?
Is it easy to understand and follow?
How often would they do this task?
Can they do it in a reasonable amount of time?
Does this make my client more productive?
Is this really filling their need?

I know of a software development company where in the 80s they created a software product for video rental stores. They wanted to be different from the rest of the competition. Everyone else used the keyboard as their only method of interfacing with the program. However, the mouse was becoming a popular standard with computers, so they decided they would use the mouse to navigate and execute transactions instead of a keyboard. They worked hard, created their first version, and released it.

There was just one problem: it took a lot longer to use the program than the competition. While one person had to move and click across the screen for just about everything, the competition could quickly use keyboard shortcuts and do the same thing in 1/4 of the time. In a retail store, if it takes 4 times longer to get customer through checkout, it is a serious problem. Not only that, but it was more work moving and clicking the mouse.

In short, while the interface was sleek, elegant, and it was easier to train, it didn’t fit the primary needs of their clients: check out clients quickly. This repetitive task wasn’t quick enough. Imagine if your IM client required 5 steps to send a message. You wouldn’t use it, it would a giant waste of time.

How To Become More Understand

I’ve jotted down a few ways a developer can work on becoming more understanding:

Meet the Client – I would suggest any key developers who will be working on the client’s project should meet the client. Developers should feel free to ask questions to help them understand better the project. I suggest the developers be briefed first by the project manager, ask him questions first, and then any unanswered questions can be asked to the client. I’ve also believe that putting a face to a name always makes business more personable.
See the Need – If at all possible developers should go and see the need that they are trying to fulfill. If you’re working on a Point of Sale program for an automobile supplies store, try and visit the client and see where your software will be at work. I remember working on a tool to help prep kiosks for deployment. The client sent pictures of the work area, and the lead developer went to visit the warehouse. See the environment helped the entire team understand the needs and challenges we faced, and helped up create a better product.
Open Communication – There should be one point of contact with the client where questions can be asked. If there is something you don’t quite understand or isn’t clear, the Project Manager should be able to get answers in a timely fashion to keep things moving along.
Frequent Client Feedback – This can be a double edge sword, and expectations about “feature-creep” should be set and kept. However, showing the client regular progress is important. Getting feedback during the entire process will actually help eliminate feature-creep at the end. While testing in the Alpha and even Beta stages of the project can be hard, using tools like Camtasia and Jing can help get feedback from clients when change is easier to make instead of a day before the deadline.
Usability Testing – Try to have an environment that is easy to quickly perform usability testing. This should be done throughout the entire development process. Like I’ve said before, its easy to make small changes as you develop. However, making a lump of changes at the end can be expensive and frustrating.

From jr. developers to project managers, it is important to understand the needs you are supose to fullfill. The reason computers and software has become to popular is its ability to make our lives easier. Focusing on all aspects of software development, and not just the technical aspect, can make the difference between an okay developer and a great one.