The “Priority Queue” Development Process

Leave a reply

TLDR – Programmers are bad at giving time estimates so we shouldn’t ask them to. To be more efficient an organization should experiment with a process that simply places 3 items in each developers ‘PQueue’ and let them finish it.

PQueue

My tech teammate was up from Austin this week and suggested that our dev team try out a process similar to what his old team used at Demand Media. The basic idea is that instead of doing agile or waterfall, DM simply assigned each developer a queue of the highest priority tasks they could be working on at that moment (with a cap of 3). I would like to dub this method the “Priority Queue” Development Process or ‘PQueue’ for short.

The Business – Programmer Divide

The business world generally runs on an organized schedule. You set meetings, sales calls, ad buys, deliveries, etc at predefined times and generally meet those obligations.

Since schedules existed long before software, most organizations try to ram their dev teams into something that nicely fits with the traditional business world. Times, dates, estimates of completion, etc. Programmers then run around behind the scenes trying desperately to meet the semi-educated estimate they gave the project manager two weeks ago. People get stressed, dates are missed, and the end result is usually a programmer ‘debriefing’ in a room full of non technical people for a couple hours trying to explain why they missed the deadline despite burning themselves out over the weekend. The very next day another ‘planning’ meeting is usually created so that the developer can try his best to give better estimates this time around before starting this hair-brained process all over again.

It’s an undeniable truth that most programmers are bad at estimating and that every programmer has missed a deadline at some point in their life. So why do we continue to measure success or failure based on whether a programmer successfully hits a time estimate? And worse yet why do we waste 5 to 10 hours a week of programming time in meetings for a process that is so clearly broken?

Enter The PQueue Development Process

As described earlier the process is very simple: Throw out all those planning/debrief meetings and give each developer on your team a list of 3 tasks they should be currently working on.

This makes life for a programmer simple. The three tasks in their queue are the highest priority item for them. They don’t have project managers pestering them about status updates or worry about missing an estimated deadline. They simply have three tasks and uninterrupted time to do them in the shortest time possible. Once a task gets completed you move it off the dev queue, into the QA queue, and then move on to the next highest priority item in your team wide ‘Priority Queue’.

What’s a Project Manager to do?

Ironically this makes a project managers job more focused and streamlined as well. The project managers main focus is to ensure that there is a ‘Priority queue’ sorted in priority order for their developers to pick tasks off of.

Additionally a project manager should ensure that their team has uninterrupted time to code. This means running interference on requests from other departments, working with QA to parse bugs, etc.

You pay programmers to program. Let them do their job in the most effective way possible.

Won’t this hurt a business development person?

There are certainly arguments to be made that this would hamper a bizdev employee; however there are positives. You may not have dates, but you do have an organized list of the companies priorities (which ironically should help give internal focus). This gives you a way to intelligently speak about the direction of the company without tying yourself down to time estimates that are bound to disappoint.

Do you already do ‘PQueue’ style development? Are you interested in learning more?

If you are interested in learning more about PQueue development style techniques or are already doing something similar I would love to hear from you in this survey:

http://www.surveymonkey.com/s/DQ9MGSV

MVLP – Minimum Viable Landing Page

Leave a reply

The Beginning

Sometimes you get ideas that simply stick with you, festering in your head day and night, screaming and yelling for you to do something about it. Unbounded by anything but your own imagination, it slowly forms into a grand vision of market dominion, bucket loads of money, incredibly happy customers, a hockey stick graph, VC money and eventually an IPO.

Baby Steps And The Lean Startup

So how do you go from that idea (worth exactly $0 at this point) to a successful company? One buzz concept that has swept through startup land is the notion of ‘The Lean Startup’ (for full details read the book), which essentially boils down to spending the least amount of resources to discover what your customers truly want. One of the major acronyms that has become popular from that methodology is that of a ‘Minimum Viable Product’.

In my opinion, an MVP is the smallest artifact that allows you to learn something from your target customer. This means that an MVP is really just a test of a hypothesis. You have an idea of what you think your customer wants. In order to validate that you need to have a goal (conversion), a tool to test that (MVP), and a relevant customer (this is really important).

Since I don’t want to jump into the argument of what an MVP truly is, I’m going to describe one way you can get feedback from target customers which I would like to coin as the Minimum Viable Landing Page or MVLP for short. Using a combination of Amazon S3, Mailchimp, Themeforest, and Namecheap you can create one for under fifty bucks and a few hours. I created one using this exact process that you can view at www.iosuserfeedback.com (and sign up for the beta!).

Side note: I encourage everyone to talk to successful entrepreneurs who are one or two generations older than you. You’ll notice that ‘Lean Startup’ is just a new label on an old idea, like so many fad cycles. Businesses have been successful for thousands of years because they provide value that people are willing to pay for.

Fighting the engineering itch

Before we begin, a word of caution. If you are an engineer like me you need to be very careful. It’s easy to fool yourself into thinking that just ‘one more feature’ will make your product suddenly viral, or tweaking the copy on a page will make your target customer sign up for your beta list (this is just optimizing a local maxima). That may work occasionally, but usually what happens is that two hours you thought it would take turns into a couple days, then you add one more feature, and soon you are on a week long adventure in engineering candyland. During that week you never once talked to your target customer, which might as well be a cardinal sin for an early stage startup. I have some specific tactics I (and my company) like to use that I like to call ‘value proposition’ testing to really extract the most relevant information from a person possible. That’s a post for another day, but the point is to try not to succumb to engineering when you could learn more from having a simple conversation.

NameCheap

The first thing you need to do is find a domain name, and I recommend using namecheap.com. Their DNS service provides a handy feature for later on in the process when we put up our static page to Amazon S3.

ThemeForest

Themeforest is a great resource for the graphically challenged. The visual design of your landing page just needs to be good enough that no one notices it (whether it be bad or good). Remember the goal here is to test a hypothesis, so unless your hypothesis has something deeply intwined with visual design, don’t fuss too much about it.

There is a section in themeforest specifically for landing pages. The example landing page at iosuserfeedback.com is actually just a modified version of Convertix.

Once you have your theme downloaded you should modify the html a bit to fit your needs. In the landing page I bought, I removed about 80% of the content, filled out the page’s copy, and then modified the hero image up top. Don’t try and do too much.

Adding in Mailchimp.com

At this point you should have your template filled out on your local machine with all of the correct and modified copy/html. The last step before putting it online is to allow people to input their email address so you can contact them at a future point in time. Since we are going to be hosting on Amazon S3 (which can only host purely static content), I like to use Mailchimp so that I don’t have to deal with configuring a server, database, or a mail server. Remember the point of an MVLP is to use the least resources possible to learn about your target customer.

In order for the form to seamlessly integrate into your landing page I would recommend using MailChimp’s Advanced Customization. This option requires a paid account, but it also means you get to fully control the HTML instead of having to deal with their somewhat crappy visual form editor.

Once you have integrated your advanced mailchimp form into your html, it’s time to put it online.

Hosting on Amazon S3

Amazon S3 is most commonly used as a storage service, but they have a handy option to turn your files into a consumer facing static website. This is very cheap and you don’t have to worry at all about scaling. After you sign up for a new account, create a bucket named ‘www.yourdomain.com’. Once you have your bucket created, upload your html and other assets. Here is what the bucket structure looks like for www.iosuserfeedback.com

 

Once that is uploaded go back to the ‘bucket’ explorer and click on your bucket. Now enable ‘website’ in the right hand side of the screen like so:

 

You should now be able to hit your website at the endpoint listed. Keep that endpoint handy, the next step is to do some final DNS tweaks via NameCheap.com

The Final Piece: Tweak DNS settings

Login to your NameCheap account, and under your domain click ‘All Host Records’. You need to add a CNAME record that points ‘www’ to the Amazon S3 Endpoint. In addition, you need to add a ‘URL Redirect’ from the root (@) to www.yourdomain.com. The URL redirect is a bit of a hack that is nicely provided by namecheap because root host records can’t be an alias like other CNAME’s. This setting neatly points your root at the www CNAME, which in turn routes you to the static site hosted on Amazon S3. Here is what my dns configuration looks like for www.iosuserfeedback.com:

 

That’s it!

That’s an easy way to create an MLVP in a nutshell. If you need help setting one up feel free to reach out to me via twitter or email (matt.sencenbaugh at gmail).

Provide Opportunities For Users to Evangelize Your Product

Leave a reply

In a pitch meeting with Dave Whorton of Tugboat Ventures a few weeks ago he said something that struck a chord with me as an entrepreneur.

 Give people the opportunity to evangelize your product.

He went on to give a few examples of products that do it well:

Nest

The Nest Thermostat is a thermostat that uses machine learning to save energy (and money) on your energy bills, but Nest also has an iPhone app that lets you control your thermostat remotely. Dave’s point here is that that iPhone app is not core to the experience of Nest at all. No one has ever controlled their thermostat remotely before, and only a very small percentage of users will actually regularly use the iPhone app to do so. Do you know what people do use the iPhone app for? To show their friends all about their cool new Nest, even when they aren’t at home.

Chevy Volt

Another product that uses an iPhone app in the same way is the Chevy Volt in conjunction with their OnStar RemoteLink app. The iPhone app is way outside of the core features of using a car; however it gives people a chance to evangelize chevy volt’s wherever they go. Instead of having to be near their car, all people have to do is pull out their phone and show people their cool new app.

The key takeaway from Dave’s simpey comment is that if you want a strong word-of-mouth or viral component to your distribution strategy it doesn’t have to be limited to social networks. Make a good product, then give people the chance to evangelize for you.

 

On Being a Junior Developer

66 Replies

Junior developer (for purposes of this post)is a developer with < 2 years experience programming in industry who have an interest in sharpening their technical skills.

I recently graduated from Stanford with a degree in Computer Science. I’ve been programming for 4 years and feel comfortable claiming ~1.5 years industry experience through summer internships, failing as a solo founder, being a lead engineer for a startup, various freelance gigs, and my current position at a mobile health startup I helped found in December. What follows is the list I wish someone had written for me as a developer starting out in the tech industry:

1) Read other people’s code

Perhaps the best way to enhance your technical ability is to directly read other people’s code. Github is a fantastic resource; and it’s even better if you have an all star developer already within your work environment that you can bounce questions off of. Here are two things I think are particularly valuable:

Focus on naming conventions; good programmers define variables with names that enhance the readability of the code and also provide intent, but also don’t couple the variable name to a certain data structure type.

Try to load the whole system into your head and understand it. Notice how the various components are decoupled, design patterns, and also how they have spelled out their unit tests. Holding well designed systems in your head is very much like visualization within athletics. Visualizing yourself in a certain athletic situation or doing a specific technique correctly has been linked to improved performance. Do it for coding too.

2) Plan things out

Before you ever start coding you should sit down with a whiteboard or pen and paper. These drawings don’t have to be complex, but should provide you with a holistic view to how all of the components you are about to code or touch should interact. In addition you should be exploring different design choices at this stage, it’s much easier to erase a whiteboard and start from scratch then be a week into your coding and realize what a mess things have become due to lack of planning.

3) Have an opinion

As a junior developer you should have opinions and you should have reasons as to why you have that opinion. Even asking yourself the question of “why did you make choice X?” as a thought experiment is a nice way to have a robust answer and solution to your problem. The reason you need to have opinions instead of simply following along is because you are literally learning into understanding. Ask yourself the tough questions so that when a senior developer reviews your code you have a legitimately robust solution.

4) Ask questions

In the very early days of my current startup the backend developer wrote an abstract base class for all of our Models in Django, which essentially acts as our very own wrapper on the Django ORM. I was reading over his code and was very curious as to why he had gone through the trouble of doing this.. after all isn’t that what an ORM is designed for? His answer:

“I did that because it makes it easy for us to change the underlying database without having huge migration issues”.

He had been bitten hard by database migration issues before (in particular a postgres to noSQL solution) and was prudent enough to take preventative action.

Ask questions about peculiar things, there is often wisdom and learning to be had.

5) Explore new technologies

One of the more unfortunate trends I see with some of my graduating Stanford CS friends is that they are often afraid to try new technologies. They have a computer science degree, not a ‘programming for industry’ degree and it terrifies them a little bit. All Stanford people have known while growing up is being the top of their class and naturally gifted. When confronted with a situation they aren’t good at they often freeze up for fear of failure. As a junior developer it is in your best interest to fight those instincts and cast your net far and wide. Every piece of technology you touch influences you in some way, and having used various technologies exposes you to new paradigms and ways of doing things. Touching a new technology / programming language is expanding your ‘world view’ of programming.

Note: The classic debate is functional vs OOP; however even something as small as giving Node.js a try can have benefits. After playing around with Node.js I now generally use their two part callback for asynchronous code because I really like that decoupling.

6) Embrace unit testing

One thing I didn’t do enough of at Stanford was unit testing. I had one TA who bugged me to do it (I still didn’t); however the rest of my classes never did. We weren’t graded on unit tests and we got to reset our projects every 10 weeks. University just isn’t built for cultivating a testing culture.

As a junior developer you really do need to embrace unit tests. I will advocate for Test Driven Development (TDD) not only because it improves my confidence that my code is functioning properly but has also really improved my function prototypes as I generally ‘call’ the function before its even built. I’m not particularly fond of BDD; however any form of testing you can do is better than nothing (trust me when it comes for v 1.1 of your app you’ll want those regression tests too).

7) Refactor

One of the problems of being a junior developer is that you haven’t been in industry long enough to be bitten by poorly written code that becomes impossible to maintain. Being a developer isn’t about writing code, it’s about producing working software while simultaneously hitting business goals and maintaining expectations. When you start with a blank slate everything is golden: you get to build from the ground up, features get spun out faster because they don’t interact with other parts of the system as much and the sky is the limit. If you are simply slinging code without any regard to maintainability, after about 6 months you will have accumulated a huge pile of technical debt. New features can’t get put out as fast, it takes longer to know what a certain function does and changing one thing wreaks havoc on another component of the system. Unfortunately the demand for new features from your users doesn’t simply decline with your technical debt; in fact it is likely increasing. This puts developers in a bad spot because they have a tangled pile of code and non technical folks requesting new features at rapid fire pace who have no idea what it means when you say ‘spaghetti code’.

So what happens next? The developers say the old system is slow and everything would magically be better if only we could rewrite the thing from scratch. So new developers are brought on to maintain the old stack and your ‘best’ developers begin creating the system from scratch. Bottom line… this is a huge waste of resources and doesn’t work anyways (it always takes longer to rewrite than you think, the new stack is always trying to catch up with the old stack, lots of QA time, etc).

But here’s the kicker, who wrote the initial version in the first place? Developers. 

I want you to imagine for a second a business development employee approach you and say “Yeah, that old partnership that is supposed to be our flagship deal is slow and I messed up that relationship pretty bad. Don’t worry though, if we go get another partnership while still trying to string the old one along we can be back to full speed!”. That’s unprofessional, and frankly so is unmaintainable code.

The solution to this is preventative medicine. As a developer you should be constantly rewriting and refactoring your code. Don’t ever check in code that isn’t a little better off than before you started. Maintainable code is code that is easily readable, extendable, and testable by outside developers.

Unless you have a very very good reason to put in that ‘quick fix’ don’t ever sacrifice a local maxima of productivity for the long term health of your codebase.