One of my favorite development processes is Kanban. I’ve used physical kanban boards with post-it notes in past jobs to keep things straight. This has been a feature of other ticketing systems for a while, it was just lacking in Emperor.

As such I’m happy to tag Emperor 0.2.1 today that includes a kanban board for every project.

In addition to the expected visualization of states via columns, Emperor’s kanban implementation also provides easy filtering to view just the tickets you are interested in. This feature is often implemented as swimlanes in other kanban implementations.

Emperor’s kanban is also implemented using JavaScript and the new search api endpoint. This means that it’s really fast!

There are many features that I look forward to adding to Emperor’s kanban but this is a great start.

Rabbit Hole: Easier Deployment

Using Emperor previously required a few setup tasks:

• Install MySQL and create user accounts
• Configuring Emperor to connect to the database and mail server
• Compilation and deployment to a server with the above

This wasn’t particularly complex but I felt that thinks might be easier if Emperor could be deployed to services like Heroku.

This idea created two problems:

• Heroku uses PostgreSQL
• Running an in-JVM ElasticSearch was difficult due it’s expectation of using port 9200.

These complications led me decide on two things. The first is that Emperor’s schema could use some small changes after lessons learned from the first version and that a simple, REST-based ElasticSearch dependency might serve better in the long run.

PostgreSQL

The change to PostgreSQL gave an opportunity to revamp Emperor’s schema. The first change was to use sequences for the numbering of tickets and the latter was to separate mutable and immutable ticket data into separate tables.

There was of course a lot of SQL rewriting to eliminate some MySQL-isms and take on new PostgreSQL-isms. Since Emperor uses a very minimal model layer it is both refreshingly free of abstraction and frustratingly prone to failure across database vendors.

In the end I feel this was a positive change that benefited Emperor and made for a better codebase for future changes.

ElasticSearch REST

ElasticSearch has an extensive Java client library that Emperor previously used via Benny Sadeh’s scalastic.

This heavy depdendency on ElasticSearch’s pile of JAR files and the fact that ElasticSearch has such a rich REST API irked me and when I ran into hosting troubles with an in-JVM instance of ElasticSearch it was the final straw. So I created wabisabi, a pure REST client for interacting with ElasticSearch.

Picking Up The Pieces

After the two above changes there was lots of fixing to be done. The significant fundamental changes to Emperor’s model made for a lot of broken functionality that requires extensive testing. This is of course not the fun part of software development, so it took longer.

Recently I resumed working on these fixes after moving from Nashville to San Francisco and today I am happy to tag a new version and to resume using Emperor for some small day to day projects.

The Future

The landscape of ticketing systems hasn’t changed much since I created Emperor just over a year ago. JIRA continues to dominate my professional career and GitHub Issues provides reasonably powerful issue tracking for OSS projects and small teams. I still think there’s room for middle ground. Maybe it should be hosted?

Working on Emperor cemented my understanding of Scala and reintroduced me to modern JavaScript frameworks. It has reinforced my love of ElasticSearch and given me many a late night of hacking. I expect I will continue developing it in the hopes of finding like minded folks who want a similar system. If not, then it will continue to serve as an excellent platform for learning new things.

Isn't Capistrano For Rails?

Capistrano — or just cap as it is often called — is widely used for deploying Ruby on Rails applications. But it's possible to use cap for deploying any type of app you like. At Twitter it's used to deploy pretty much anything you can imagine.

So I set out to use it for Emperor because it's deploy and rollback process is quite nice. Here's how you do it.

Going Off The Rails

I'm assuming you've already got cap installed. If not then do read the docs.

The first step is to install the railsless-deploy gem. You can find instructions for installation and use in the linked documentation. If you check the docs it will advise you toward a simple Capfile.

Actual Deployment

Here's a complete Capfile with comments explaining the bits.

Conclusion

Capistrano is a great tool but I've find it to be poorly documented. The above Capfile took me a few hours to piece together. That being said I'm very happy with how it works! Hopefully this helps other Capistrano users that are deploying non-Rails systems.

• There is now an edit button on the ticket view page. (EMP-2)
• A ticket’s resolution status is now clearly shown on the ticket view page (EMP-3)
• Reporter now defaults to the logged in user when creating a ticket (EMP-4)
• Resolution status (via strikethrough) and summary are now shown in links (EMP-6)
• Ticket creation now shows up in the timeline without a reindex (EMP-7)
• Project is now listed as the first item in ticket creation and editing (EMP-8)
• Revamp search results page to show more information (EMP-9)
• Ticket links are now styled
• Ticket links can now be removed (and have an API call)
• Add more API docs (but they are still bad)
• Change color of search filter buttons

I’m planning my next sprint now and it is likely to involve further link improvements and project-level settings for ticket attributes.

But that didn’t stop progress!

Today I tagged version 0.0.4 which includes the following features:

• Events and Timelines
• Ticketing linking (blocks, relates to, etc)
• Lots of unit tests
• Ticket advance & revert UI
• Lots of UI polish

Some highlights of features I’m working on now:

• General features
• UI improvements
• REST API

There are screenshots on the GitHub page. A lot of the core functionality is complete for version 1.0, but there is a lot of fit and finish work to come on the UI. Stay tuned for more!

Meet Emperor!

What

Emperor is a project management system for software development. You can also call it a bug tracker. I don’t mind.

Why

I’ve spent the last 5 years acting — in one capacity or another — as a manager of developers and of development process. I feel that I’ve learned a lot about these sorts of things. I’ve worked with both engineers and non-engineers and I feel that there can be a lot of improvements in these systems.

Also, I think the world could just use more of me.

How

Emperor is available on GitHub. It has instructions for anyone brave enough to use it at this point.

Current Status

Emperor is minimally functional at present. You can create, progress and manipulate tickets and perform many administrative functions. Unfortunately there are bugs lurking all over the place and plenty of half-completed features. For personal reasons it was convenient to release it to the world today.

Other Details

Emperor leverages my recent infatuation with Scala. It has been a learning experience and will likely undergo significant changes as I become a better Scala programmer and learn to better leverage the Play framework.

The Future

It is my intent to finish an installer over the coming weeks and to release a 1.0 version with a small but convenient number of basic features. Afterward I will begin refining and adding new features. Remember that your assistance is welcome!.

How and who to hire has been beaten to death. I will only touch on specific gems I’ve learned in my time.

Don’t Hire A Warm Body

“This person isn’t so bad”, you think. “They’ll do for now, we just need a warm body.” Bullshit. This has bitten me in the ass every single time I’ve done it.

Time

Hiring people is a full-time job. Writing the job up, posting it to various outlets, handling candidates, performing phone screens, conducting interviews, conducting second interviews and negotiating hiring can become a huge time sink. It is vitally important that you set aside plenty of time for this process. How can you expect to get a great hire if you don’t spend the time?

If you task someone in your organization with finding talented developers then please give them adequate time and patience.

Skill Level

Hire the best person you can find and afford. Many companies get sticker shock at developer salaries. It’s a highly skilled and high demand job. As a result they try and skimp by hiring juniors.

Juniors are junior for a reason. They still need to learn. They do this best at the hands of a more senior developer.

Hire the best developers you can find and work your way down. It’s very hard to build a solid structure on a weak foundation.

Sources

Where can you find great developers? Lots of places!

Recruiters

Recruiters, job boards, friends and peers. Your network is always a great place. Use your LinkedIn network!

Boutique Job Boards

There are lots of great job boards these days that are focused on developers. Using one of these boards helps to show that you’ve done some research and hunted for your quarry where it lives!

• Authentic Jobs
• GitHub Jobs
• Gun.io
• Stack Overflow Careers

Conclusion

Reading this should’ve helped you see the work you need to do. Hiring good folks is hard. Be prepared!

Note: This guide is meant for hiring developers, but most of the advice is useful for hiring any position. Learning your employees and treating them properly is just a damned good idea.

Make A Plan

Read through this and all my other advice. Get a plan together that your organization can pull off.

Get Your Mind Right

Have you ever been talking to your mechanic and realized that he's asking you very specific questions all you can do is make noises at him? Talking to a specialist in any field often works this way.

We'll stick with a simple explanation for developers: Developers think in a different language.

Learning the innards of computers and the magic that drives them makes fundamental changes in your brain. Developers tend to ask hard or obtuse questions about the tasks you give them. You need to prepare for this. It's no different than talking to a doctor or mechanic.

Simple advice: Spend extra time with your developers. Learn how they think, talk and act. As with any relationship it pays to invest in it. Expect that they will do the same for you. Teach your developers about your business so that they can help you with better solutions.

Space

I have scaled advice for making space for developers. I will present the options from best to worst. Choose the best you can manage:

• Give every developer an office. Folks smarter than me have been saying this for years.

• Let developers share offices. Be careful who you pair. Encourage open, honest communication and basic neighborly behavior.

• Isolate developers. Give your developers quiet space to work so they can focus. Show me a noisy, distracting environment and I'll show you unproductive and unhappy developers.

• Create cubicles with some privacy. High walls, sound dampening, etc.

• Basic human decency: Enforce headphones, ban speakerphone, discourage phone calls.

I also highly encourage you create some common space for your developers to meet, hack as a group or just to hang out in. Fill it with whiteboards, some Nerf guns and some Red Bull. Use this space for everyone, not just your developers. Encourage this space to be used for hallway meetings, impromptu discussions or phone calls. This will keep your working area quiet.

Telecommuting

It's never been easier to telecommute. Combinations of Skype, IM, group chat (Basecamp, HipChat, Flowdock) and cloud-based systems mean that folks can work together from anywhere in the world.

That being said telecommuting has it's own problems. It's definitely not for everyone. Employees need a quiet, dedicated work space and a close attention to how they spend their time. If you can overcome these challenges then you open yourself to a huge number of talented developers and cost savings. I'm planning to write an entire article on telecommuting in the future.

Gear

Developers don't use computers the way normal people do. Imagine a race car driver hopping into your car and taking it onto a track. The driver would not have the equipment they need.

Developers need to perform tasks with their computers that are very intense. They need powerful processors with lots of cores, lots of RAM and big hard drives. They also need to install and fiddle with lots of software. Your current purchasing and IT policies may not fit. They may also need to be mobile. The best advice I can give is to give your developers a short list of approved hardware and let them choose. Pick a powerful desktop and a powerful laptop.

Big ass monitors. The biggest you can afford and as many as you can plug in. This is pretty much universal.

Policies

A lot of your policies will depend on your business. Many organizations have to worry about compliance with various regulations. You should already know how this works, so I won't help. Start with this advice and prune it back: Give your developers freedom. Teach your developers about the policies your company or industry must adhere to. Developers want to know why they must do things.

Developers can usually fix their own machines and they are little risk for viruses or malware. They often need to install crazy software that requires total access to their machines.

Conclusion

Don't stress getting everything in this list perfect. Getting even a few of these criteria in place makes you very attractive to developers.

If you think all of this is crazy then I suggest you go back and determine if you really need to hire developers.

Why Are You Hiring Developers?

What are you looking to accomplish by hiring developers? Are you really a technology company? Will you be able to properly care for and nurture a group of developers?

Hiring developers brings a whole new angle into your company. These people think, act and work differently. If your entire company is currently marketing or sales then you may be in for a real culture shock.

Outsourcing?

You should almost certainly outsource.

There are lots of consultancies and outsourcing shops that would love to have your business. These organizations make it their business to hire and care for developers. They save you the hassle! If you are really a marketing company or a manufacturing company you might save yourself a lot of headaches by outsourcing.

This is good advice for any person you are looking to hire. Do you have enough demand and enough desire to hire a full-time person or group to do a job? It's especially important when you are looking into a discipline that isn't your core business.

Another problem: Are you qualified to interview and evaluate developers? Most people in the technology business aren't. It's daunting.

A Note On Outsourcing

Your problems aren't likely that unique. There is almost certainly something out there that can do what you want. Would you build your own car? Your commute isn't that special. Neither is your problem.

If you need a simple website then use Squarespace and get your social on with Twitter. It's never been easier to have a web and social media presence without a CompSci degree. Very, very few companies need a custom solution. This is usually what gets them into trouble!

Use a consultancy to help you find something that fits. They might try to steer you the custom route for more billings. Keep an eye out for that.

If You Do Need Developers

You still want to hire developers, eh?

Fine. Maybe you do need developers. That's great! Tune in next time and we'll cover how to go about hiring what you need!