I’ve seen a lot of posts recently about how to go about hiring hackers. Well not just recently, it seems to be common thing people ask, because it’s one of the hardest things to do. You’re using an interview, or even a series of interviews to try your best to determine if the person is going to be up to the task.

The problem is of course, you’re really just determining if the person interviews well, or if they’re the graduates that they’ve got good marks. The real problem is of course neither of the two matter because neither of them have much if any bearing on how good a coder a candidate is going to be.

The problem is exacerbated in a startup because unlike some of the more successful bigger players you really can’t afford to take people on a trial basis for 6 months. What can a startup do?

There are a lot of universities that run placement programs for their students, programs allowing them to get real industry work experience. I’ve also worked in companies that made it a policy to hire students for internships then offer the best jobs once they’ve graduated. It was a great way to get talent.

What if you need to hire to fill a more senior role, or you’re not hiring at the right time of year? Student internships usually start once at the same time every year so unless you’re looking for fill a role then, you’re shit out of luck.

I’ve toyed with the idea of a ‘hacker camp’, getting all the candidates together, and paying them to work as consultants on a project - then hiring the best into permanent positions. All the candidates need to be free to work on the project, and a lot of people would be pretty scared to leave a job to take part and some jobs would prevent them from working on the project, so running it over a weekend might be a good idea, but it limits the scope of your project. You’d also still need to have interviews, to make sure you were getting candidates who were really interested in the job, and also to weed out any candidates you knew were totally unsuitable.

I think it’s important that a ‘hacker camp’ should produce something at the end of the weekend and you should get as much of your existing staff involved as possible. To make the cost easier to swallow you could even go so far as making the deliverable a new feature or part of your existing product but that’s not as important as actually delivering something, because that will be the bottom line when it comes to integrating them into your team.

Related articles by Zemanta

• Learning from a summer intern program
• Fuel business growth employ an intern/apprentice
• Companies get more savvy with internships to find next-gen IT workers

As I’ve announced here, we’ve recently taken the difficult decision to put development of Citrus in hold, indefinitely (let’s be realistic, probably forever). I’m now wondering what if anything we should announce about our new project.

Is openness a strength or a weakness? Is there value to the community in publicly documenting our design decisions, and how we’ve come to them? Is it something our competitors could and would use against us? Is there anyway to mitigate the effects?

I like what Jeff Atwood and Joel Spolsky have done with their series of podcasts on the Stack Overflow blog where they’ve released their design meetings as a series of podcasts and given us all an insight into how they’ve come to some of the decisions they’ve taken. But let’s face it I’m neither Jeff or Joel and I don’t get anywhere near their traffic. So the first obvious question I’m asking myself is if it’s even worth the effort of writing posts, let alone recording and releasing podcasts.

Next is the question about maintaining a competitive advantage, given the fact that our team is so small, just the two of us at the moment; I’m only working about half time on the project and Simon, who isn’t a coder is working even less. So giving someone a guide to competing with us could be downright foolish. Then again, nobody is really listening are they? So does it even matter?

The other question, which I think is equally important as the project grows - hopefully into a product is what if any level of openness is appropriate post launch? Will an open discussion of ongoing design decisions as they’re being taken before, or even as they’re released be of any benefit to the community? Communities can be some of the biggest supporters and can be some of your most passionate users - sometimes these passions can work both ways? What level of support ongoing will a public discussion of the decisions you’re taking, before users have all the prototyped interfaces to play with, be required? Is there an ongoing effort you’ll need to make to maintain the level of trust and confidence of the community?

I think I’ve talked myself out of a podcast of our internal discussions, for now - but I’m still keen to use community interaction to help us develop a product that meets the needs of the people who are interested in using it and to drum up support and interest in the project. I’ll no doubt return to this topic in the coming weeks as I develop a clearer idea of how I think we should accomplish that.

If any of the few of you out there listening have any questions or comments, please let me know your thoughts.

Related articles by Zemanta

• Does Good Tech Need PR?
• stackoverflow.com
• PR-less launch kicks off a stack overflow of praise

First we started to explore, then quickly we needed to figure out where we were and we’ve been building increasing numbers ever more sophisticated maps, guide books and other sources of location based information ever since. The extension of this location based information to mobile Internet enabled devices is the obvious next step and potentially huge market. Just think of all the location based data people pay for:

• Mapping probably the biggest market segment, and the first which we’ll see device convergence. Look to see the traditional GPS hardware/software become applications for the current and next generation devices.
• Reviews A common feature of newspapers, local and region
• Business Directories again, think of the big yellow book of business for every area. It’s one of the most common things to look for in an area.
• Travel Guides More than just reviews, travel guides also provide us with areas of interest and all of that is very useful in an up to date online service

All of this is pretty obvious and most of it exists now. The problem up to now has been the walled garden approach taken by the mobile phone companies. They had the ability to determine position, but wanted to charge for it. Unfortunately for us consumers, charging for that data has meant that for the most part services would need to turn a profit for every single request, from the start or they’d be very expensive to develop and very quickly.

Mobile data has recently become very cheap and new devices with integrated ability to determine their location is having a profound impact on the mobile landscape. They’re allowing us to build services which instead of answering the question: where is my nearest X, will let us explore the area around us. Mapping the wealth of knowledge on the internet to physical locations and allowing us to actually input data when we’re most likely to want to - when we’re actually there.

From experience, when I’m out there the data I want most is about out there.

Related articles by Zemanta

• More on the state of the mobile web
• Travel sites wake up: Nokia to offer €8 mobile Lonely Planet guides

I think it’s clear now, despite all the best hopes of an easy ride, that the economy has gone to shit. I also think it’s clear that no matter how far you try to bury your head in the sand, it’s affecting tech and other industries now. The knock on effect has a arrived and the inability of some to get operating credit as well as the fear of not being able to get credit if they might need it has lead to some belt tightening already, and there is more of that to come.

Maybe it’s a little cynical of me, but I think that some consumer websites which are lean and well capitalised must be liking the idea that people are going to be out of work. I mean without their boss bothering them to get off facebook and do some work - they can just do that all day, can’t they?

Really though, I think this time around the Internet is probably one of the better placed industries. We’ll feel it less and later than others and we’ll come out of it better off and earlier than some. Big ticket items are going to be the first to go, houses and cars are already down and falling fast. Holidays are out, entertainment and going out is suffering and it’s bound to get worse. That’s going to leave people with more time to waste, at home in front of their TVs and in front of their computers.

When confidence and spending starts to rise again, we’ll start to see people with a little money chasing bargains with time on their hands - isn’t that what internet shopping is all about?

The core fact of the matter is the economy is in the shitter because of banks - there is nothing fundamentally wrong with tech companies today. It’s not anything like the previous bust, it’s not a correction reigning in stupid valuations for companies with no clear path to revenue let alone profit.

Is it a good time to start a company though? That depends on how much if any investment you need. If you can bootstrap, and you should, then it’s a great time. If you’re going to need to find investment to get your idea off the ground, you’ll have a hard time with it. Until we can see the light at the end of the tunnel, and we’re sure it’s the end of tunnel investors are all going to assume it’s just a train.

A bit latter than normal, sorry about that. I’m really trying to maintain the post a day thing and I’ve been scheduling them in advance - I didn’t get a chance to get one scheduled for today so it had to wait till work was out of the way. I’ll endeavour to try harder.

Don’t write spec documents, throw away any you have near you, they’re next to useless anyway. It might seem like a hearsay to some but it’s true and deep down even the most most anal planner in all of us knows it. Two of the biggest reasons for this are:

• size and scope: In order to address every aspect of your project a full specification document has to, well address every aspect of your project and it’s going to be huge as a result.
• lack of vision: For most people relating what’s written on paper to a vision of a design in their heads is difficult if not impossible.

Loose documents don’t work well either, because leaving the obvious unsaid just leads to problems, chiefly not everything is obvious to everyone. The devil is in the details and avoiding them until the end of a project is just going to cause trouble.

“Why haven’t we implemented x, that should have been obvious!”

create the interfaces

Prototype the interfaces and use them as your spec. Working this way has so many benefits, try it once and I promise you’ll be converted. Before you write a single line of backend code, sit down and work out your interfaces. Build each screen, put all the buttons, fields and elements on the page

I normally start with index cards and write a few simple requirements for each screen or page - just a few simple sentences listing what the page is expected to achieve.

My next step is to turn those requirements into interfaces.

in HTML, not photoshop

Photoshop is great, but let’s face it it’s no better for trying to work out a functional interface prototype than some paper and a pencil. It’s very easy to focus on making things look pretty over making them functional and you risk missing something important out.

The best way to avoid both of these traps is to write your interfaces in HTML, mark them up semantically as they will be marked up in the release and use them as your working spec.

I know good design but I’m no designer

Another benefit of coding up your interfaces in HTML before you start writing code is you can hand them off to designers so they can make them look pretty as you’re working on making them work. I have a pretty basic idea of design principals and the tools - but I find it hard work. So with interface first development I don’t have to think about it.

let the testing begin

Another thing which is made infinitely easier with interface first development is functional testing, because your testers don’t have to wait for a release before they can start developing a test suite. You are using an automated test suite aren’t you? By generating interfaces as developers add functionality testers can already have been through the interfaces and written a whole series of failing tests.

updating later

The great thing about using HTML as your design and communication tool is that when it comes to making a change to a page you have the most up to date working copy there ready to modify in the form of your site. Just save the page, add the change to the HTML and you’ve got your interfaces ready for discussion and later implementation. What could be easier, faster or more clear for everyone?

it’s not a panacea

There have been times when I’ve been working with notoriously difficult individuals where nothing was going to satisfy. An exmaple that springs to mind is a multi month project where we produced an interface design early in the project. The design was a set of PDF images not HTML (see above), but the delivered product was a pixel perfect implementation of it. Only once the project was delivered was there any input on the design or functioning of the project - I’m not just talking things that a PDF can’t show you like what clicking a link looks like. I’m taking basic things like colours, layout and the size of elements!

Would a HTML mock up have made any difference, I actually doubt it. I take blame for miscommunication and resulting mistakes when it’s my fault but in this case even after the site was fully developed and deployed to a staging area for testing none of these issues were highlighted. It was only after the site was put into production that these “critical issues” were discovered.

After reading this post what Jamie said hit me as well:

This is when I realized how trained I was in the processes at my former workplaces. This email would have been delayed until it was perfect[...] After fixing this there would be another thing and then another thing. A 2-day project would drag on for a week of redesign, approval, and development[...] It’s one thing to read Getting Real [...] It’s another thing to actually practice the principles. [...] That part is trickier than you think.

I don’t think it’s just Jamie and I don’t think it’s just his former workplaces. We’re all trained to make excuses not to launch, it’s endemic in the culture of most organisations. We endlessly pay lip service to the principals of release early and release often, agreeing in principal
with the principals - but put very little of them into practice.

A manager’s role is to facilitate an organisation’s march towards better - all too often it’s a weak manager that needs constant input on projects and at the root it’s fear of inadequacy on their part that builds a culture of ass covering. It’s obvious that at 37 Signals they don’t suffer from being crippled organisationally when executive decisions need to be made but executives are absent. Their staff are trusted to make decisions and they’re empowered to release better features.

When your last change was ready to deploy, when it was better than what was there, did you release it? If not, how long did it take you to get from that point to actually releasing it and how many people had to give final approval?

Why not empower your staff with a simple test - Is it better than what we have? No flow charts, no organisational hierarchy; just a simple question.

A few months ago we announced Citrus, a suite of tools we’d been developing for estate agents. Despite our bullish attitude to building and selling the application we’ve taken a step back over recent weeks and taken a long hard look at what it is we’re doing. The result of the look is a change of direction, back to some ideas we’ve had in the past about personal search, bookmarking and some location based services. It’s a bit too early to get into too much detail about what we’re planing but I wanted to take the time to give a bit of an explanation of why we’ve changed our minds. 

The market has changed, there is no doubt, but we know that. On reflection though we decided our assumptions were probably wrong. We knew there were not going to be a lot of new players entering the market but existing businesses probably aren’t going to want to change, software tools and they’re not going to want to part with money especially if they had already paid to have a site developed and especially if they’re being forced to lose people.

Then came the next blow to the project,  we were asked to shut down the only current user of our software. They’d decided to put their business on hold because of changes to the Spanish regulations and the current state of the market.  So now we were facing selling a product, in an unfriendly market without our evangelist. 

I’d also be lying if I said that we had generated the interest we’d hoped to generate, we didn’t. It goes without saying that had we generated that interest, or close to that interest we wouldn’t have had the moment of introspection and we wouldn’t have needed to take this difficult decision.

I’ve been trying to figure this out for months, and thought it should have been simple. All I wanted to do was write a set of unit tests to test my java code, have them run whenever I hit test. Next I wanted to have a set of HTTP Unit, Selenium or similar tests run to test that the actual application is working when it’s built and deployed to a container using the cargo plugin.

I didn’t really want to have a separate project to do this because it seemed like a massive pain in the ass to maintain the whole thing. I didn’t see any reason why it shouldn’t be easy with Maven either - it does have a phase for integration-tests already.

My first try looked good to me:

...
<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <excludes>
                    <exclude>**/integration/**</exclude>
                </excludes>
            </configuration>
            <executions>
                <execution>
                    <id>integrationtest</id>
                    <phase>integration-test</phase>
                    <goals>
                        <goal>test</goal>
                    </goals>
                    <configuration>
                        <excludes>
                            <exclude>none</exclude>
                        </excludes>
                        <includes>
                            <include>**/integration/**/*Test*.java</include>
                            <include>**/integration/**/*Test.java</include>
                            <include>**/integration/**/*TestCase.java</include>
                        </includes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>
...

I tried to run the tests, but unfortunately when it gets to the second round of tests - which should run my integration tests - it runs the same sets of as it ran the first time. I tried adding the combine.children="append" attribute to the includes, and excludes but that didn’t work either. Finally I came across a source file XppDom, part of plexus which maven uses. XppDom allowed the combine.children attribute as well as another I haven’t seen mentioned anywhere else childMergeOverride. I added that instead and it worked!

...
<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <excludes>
                    <exclude>**/integration/**</exclude>
                </excludes>
            </configuration>
            <executions>
                <execution>
                    <id>integrationtest</id>
                    <phase>integration-test</phase>
                    <goals>
                        <goal>test</goal>
                    </goals>
                    <configuration>
                        <excludes childMergeOverride="true">
                            <exclude>none</exclude>
                        </excludes>
                        <includes childMergeOverride="true">
                            <include>**/integration/**/*Test*.java</include>
                            <include>**/integration/**/*Test.java</include>
                            <include>**/integration/**/*TestCase.java</include>
                        </includes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>
...

Setting it up for Cargo

I’ve done this on a few projects, the first was a project that built a series of taglibs which are used across a number of applications. The release for the project is a jar so I have a separate test web-app structure in ${baseDir}/src/test/web-app. The code for generating this war looks like this:

...
<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <executions>
                <execution>
                    <id>generate-test-war</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>war</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <warSourceDirectory>${basedir}/src/test/webapp</warSourceDirectory>
                <warName>${project.artifactId}-test</warName>
                <webappDirectory>${basedir}/target/${project.artifactId}-test</webappDirectory>
                <primaryArtifact>false</primaryArtifact>
            </configuration>
        </plugin>
        ...
    </plugins>
    ...
</build>
...

During the pre-integration-test phase the above simple generates a test war. If you’re project is a web-app and it already generates a war you can skip the above as one will be generated for you already.

The next step for was then to get Cargo to deploy the application:

...
<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.codehaus.cargo</groupId>
            <artifactId>cargo-maven2-plugin</artifactId>
            <configuration>
                <wait>false</wait>
                <container>
                    <containerId>tomcat5x</containerId>
                    <zipUrlInstaller>
                        <url>${integrationtests.tomcatURL}</url>
                        <installDir>${installDir}</installDir>
                    </zipUrlInstaller>
                    <output>
                        ${project.build.directory}/tomcat5x.log
                    </output>
                    <log>${project.build.directory}/cargo.log</log>
                </container>
                <configuration>
                    <home>
                        ${project.build.directory}/tomcat5x/container
                    </home>
                    <properties>
                        <cargo.logging>high</cargo.logging>
                        <cargo.servlet.port>8080</cargo.servlet.port>
                    </properties>
                </configuration>
            </configuration>
            <executions>
                <execution>
                    <id>start-container</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>start</goal>
                        <goal>deploy</goal>
                    </goals>
                    <configuration>
                        <wait>false</wait>
                        <deployer>
                            <deployables>
                                <deployable>
                                    <location>${basedir}/target/${project.artifactId}-test.war</location>
                                    <type>war</type>
                                    <pingURL>http://localhost:8080/${project.artifactId}-test/index.html</pingURL>
                                    <pingTimeout>300000</pingTimeout>
                                    <properties>
                                        <context>${project.artifactId}-test</context>
                                    </properties>
                                </deployable>
                            </deployables>
                        </deployer>
                    </configuration>
                </execution>
                <execution>
                    <id>stop-container</id>
                    <phase>post-integration-test</phase>
                    <goals>
                        <goal>stop</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>
...

Most of this is pretty self explanatory, I try to use parameters to configure as much as I can and try to maintain it in higher level POMs wherever appropriate. This is especially true for the tomcat URL which changes on a regular basis. The seem to post new releases and remove the older ones, and it can be a chore to keep up in multiple projects. You may want to look at the cargo plugin documentation, you can ignore some of what I’m doing above if you’re project’s default artifact (the one package creates) is a web-app. 

So there you have it, eventually I got there after a lot of digging. I’ve been pretty brief in my explanations and have assumed a fairly good understanding of maven. if you have any questions by all means leave a comment and I’ll do my best to make it clearer.

Related articles by Zemanta

• Testing Is Not Technically Hard, It Is Hard Because It Requires Clear Thought and Understanding
• Why do we (not) write tests

Coders, desginers even your support staff actually want to take pride in their work, the want to do a good job. As a manager you’re meant to make that easier, but what if you don’t want to - how would you go about breaking someone’s will and what would a completely demoralised staff member look like, want to find out?

Start by micromanaging them

Assume from the start that they’re incompetent, they won’t get it right and make absolutely sure they’re told every task they need to do. Make sure you tell your staff in minute detail how you want it to look, how big you want it, what colour and how they should discuss it with customers - because let’s face it, the fuckers aren’t capable of figuring it out themselves.

Free will is alright in religion, but not in this workplace!

Make sure you’re ever vigilant and make sure you’re giving each member of staff a list of things they need to do. Of course there are things that will crop up and they’ll need to address those as well, but don’t allow it to impact your lists - you are the boss and your will, will be done.

The key to true micromanagement lies in the process, or more to the point in creating a process. When something slips through, there is a failure or anything breaks down it’s because of a procedural failure, the only solution is to fix the procedure, with a new one. Creating a new process allows you to have complete control without requiring you to interact on a case by case basis; though that is highly recommended, because as we made clear earlier - the fuckers just aren’t capable on their own.

For the advanced, micromanaging further can be a worthwhile challenge; take a task you’ve assigned and make sure you’re staff are aware of each step that you need them to complete. Basically micromanage your micromanaging! Tell them what to do and how you want them to do it, tell them in detail and make sure they know you’re doing this because it wasn’t done right last time and we just can’t afford any more mistakes.

Documentation is key

We all know that documentation is important, but only a gifted few are able to take it to the next level. If you’re in charge of anyone for the love of god, cover your ass. As in the wild if you’re the alpha male (or female) you need to defend that position, show any weakness and someone will certainly try to unseat you - make them document their worth, then use it against them!

As you micromanage processes and create new ones you’re handed a golden opportunity for documentation, new spreadsheets, new flow charts and new forms to fill in!

Make it pointless

It’s not meant to be about something that is easy for the staff - this is about you. Make sure the documentation is unweildly at the very lest - shooting for downright maddeningly pointless is of course the ultimate goal if you want to truly demoralise people.

Timesheets are a great starting place. But they should never list time on task - they lying bastards always just add them up to make a full week work, even when you know they’re bunking off. Make they list the time they started, then the time they finished a task and make them do it in a separate document for each task. Another great place is a call logs and error reports - make them document it all!

Make it feel like they’re justifying themselves

Make sure that when someone is filling out documentation, especially things like timesheets, they’re aware the true intention of the activity is to justify themselves. Make sure you say, and repeat, things “They’re kept on file for management review, internal accounting and cost/benefit analysis”. That’ll keep ‘em on their toes.

Make them justify themselves

Use the documentation in meetings - they knew you were going to even if you said you wouldn’t. Haul them out during a performance interview and you’ll have everything you need to keep costs down.

Advanced documentation

• Make sure it’s on paper, as we can’t trust these computers
• Even better, mandate they fill in a spreadsheet, print it and then file it
• Even better, mandate a more detailed format, update a communal spreadsheet (stored on a shared drive and only accessible by a single user at a time), print it, then file it.

That was fun, where to from here?

Now that you’ve moved away from the traditionally held position that lower level tasks should be delegated down the chain of command so you can focus on the higher level tasks, start complaining that your staff are useless. Tell them that they can’t seem to accomplish anything without you hand holding them. Put pressure on them, make them sure that THEY are holding up business development.

Hire them a new boss

You need help, your staff are useless so create a new tier of management. Hire someone from outside to help you better manage your staff. Even better, bring someone from a different division into the team and put them above the team members.

The above is satire, I wouldn’t actually suggest you do any of that if you want to have a happy productive workplace. To a greater or lesser degree I or people I know have been guilty of some of them but it isn’t based on any real concrete experience.