Joël Cox

Getting to the real problem

Wed, 25 Sep 2013 20:50:00 +0200

Writing requirements is hard. Writing good software without proper requirements is even harder, at least if you want to have a happy customer at the end of the project.

The everlasting paradox in requirements engineering is that you are trying to get an insight in the needs of stakeholders, even though the stakeholders often don’t know what they need. When they do know what they need, it’s not uncommon for them to get it wrong.

We - software developers - often skip right to the solution and you can’t really blame anyone for falling into this trap. Are you supposed to read the stakeholder’s mind? In order to find a proper solution you have to take time to understand the real problem and context.

The requirement engineering process might look a bit like a dark art for the uninitiated, but there are some really simple tricks to get to the bottom of the problem in your problem definition phase.

This article was inspired by a guest lecture from Klaas Jan Wierda at Océ. Thanks for giving me some insight in your requirements processes.

Context inquiry

When you’re in the business of optimizing or automating workflows (who isn’t?) it is of massive importance to actual have a clear view of what these processes actually entail. A process always has a bottleneck but actually identifying the problem might not be apparent to the person performing the process.

In a context inquiry you visit the user’s workplace and literally watching them do their work. This includes their time in front of the computer as well as other tasks. There is no fabricated, make-shift process, only the real, raw thing.

Following a single person (for a part of) a day will help you develop a certain empathy for the user. You are the fresh set of eyes that should spot the different problems the user runs into throughout the day.

During the session you collect a wide variety of qualitative data, ranging from interviews, videos of processes or even GPS waypoints. After the sessions you can use this data to analyze the processes, convince other stakeholders or even use it to get the development team up to speed. Clear problems often come with clear solutions.

Problem trees

A problem can be the consequence of different actions and not necessarily single one. Humans have a hard time actually mapping these interdependencies mentally. Keeping an open mind when you think you’ve found the cause is hard, especially when you don’t know the full context.

A problem tree helps you change your perspective on a single problem and will often make you realize that introducing yet another system is not best or only solution. Maybe a company is better off changing one of its policies or hiring extra staff.

Making these kind of trees is often interesting for layered problems, problems that span a longer time or multiple stakeholders. Capturing this in text is hard and these trees often develop throughout the discovery processes.

The five why’s

The easiest technique for getting to the real problem is repeatedly asking why a stakeholder wants a certain solution or has a certain problem. You can compare this to traversing a problem tree. A typical transcript of replies for a company that wants an iOS application might look like this:

Every company has one!
Because it allows people to read about our company on their phones.
Because our normal website is hard to use on small screens.

In this case you might end up recommending a mobile/responsive site rather than a native application. You probably won’t even need five why’s (and I wouldn’t recommend literally saying ‘why’ five times in a row) to get to the real problem.

Another paper tiger?

Some projects don’t need extensive requirements or clever techniques to gather requirements. In smaller companies or organizations with clear processes there is not much use to have such an extensive discovery process. Just make sure you really know what the problem is.

Another thing to consider is that changing requirements up front is really cheap. You’re better off spending two extra hours talking with your customers than ten hours rebuilding part of the system (unless you’re paid by the hour of have a good contract..). Good requirements help a long way in creating better systems and ultimately happier customers.

Building a product for non-technical founders

Wed, 18 Sep 2013 23:00:00 +0200

You’ve come up with an idea, did some lean product testing and now all you got to do is building your actual product. The only problem is that you no technical skills to speak off… At this point you only have two real options; find a technical co-founder or hire someone to build your product for you.

The first option sounds easier said than done; unless you’re well-connected the chances are slim you’ll find someone with the technical chops and the same passion for your product as you do. That leaves you with the latter options; hiring a developer.

Over the years several potential startup founders approached me to build the first version of their product and these are the things I told them.

Learn how to program

No, you’re not expected to write your product on your own, but knowing just a little about programming will earn you some major street cred and it will give you some better understanding what your developer is doing all day.

Programming isn’t hard (software engineering is!) and there are plenty of resources out there to get you started. Set aside a few hours on your weekend to get the basics down. Every manager should know about working in the trenches.

Sharpen your bullshit filter

The tech industry–like every other industry–has a lot of buzzwords. If you don’t have any technical background it’s easy to hide yourself behind a wall of jargon, so it at least looks you know what you’re talking about.

If you approach a developer with the request to build an application with a NoSQL data store because you want your product to be web scale, I can almost guarantee you won’t get a serious reply on your cold email.

Instead, reason from a non-functional requirement perspective: “We want to provide a desktop-like experience, so a single-page application sounds like a good fit.”

Don’t be a victim of NIH

Every developer has issues with the Not Invented Here (NIH) syndrome from time to time. There certainly are cases where reusing an existing component is not the right choice, but always ask your developer whether using an existing tool isn’t a better idea.

This doesn’t only save time, but also offloads part of the documentation-burden to the projects you’re using. Using popular open source software also helps when you’re bringing new members on the team; they might already be familiar with the tools you’re using.

Create value immediately

Software projects are expensive, complicated and time-consuming. As long as you haven’t shipped you’re product, your not making any money or getting traction. You’ve probably heard about the Minimal Viable Product concept, but let’s take this a step further.

Imagine you’re building an ecommerce platform. Typically, developers will start out with inventory management, but instead this developer decides to get payment processing done first. Consequently, the company that hired him started selling a single product, every week, two weeks into the project. (Example courtsey of Renzo Slijp.)

This example doesn’t translate well to every product, but it’s certainly helpful to first hash out the part of the product that makes it unique first. This allows you to show potential customers (or investors) what your product is about.

Hire a communicator

When you don’t have any technical insights in the complexity of your product it’s hard to scope and thus budget the development of the project. Some functionality will be easier to build than others; prioritize functionality together with your developer.

Your developer can also function as a hired co-founder to bounce ideas of. Great developers will think along with you and offer their suggestions throughout the project. It’s therefore incredibly important to “click” with your hired gun.

Pick your stack wisely

When you start looking for a developer you’ll notice they all seem to program in different languages. What’s that all about? Without going all Computer Science-y on you, there are two things to consider:

Are you building on an existing platform? Working on something for iOS and Android? You’ll probably want an Objective-C and Java programmer. Targeting Windows? Look for a C# engineer.
What languages does your local talent pool speak? Some languages are more popular than others and adoptions rates vary regionally. You’ll find more PHP programmers in the Netherlands compared to Pythonistas.

Of course there are technical as well as cultural implications of choosing your stack. Don’t get carried away by the fanatics and consult a few of experts before deciding.

Insist on docs

Almost every software developer hates writing documentation, but insist on having some written anyway. Don’t have your developer write documentation for the sake of, but actually make it useful. Make sure it includes a system overview, design decisions and system requirements.

The requirements document will be the first check whether the things you told your developer were actually understood. The other parts mainly serve so introduce other people to your system. Try to have as little documentation written as possible, but not too little. Documentation requires maintenance as well.

Closing thoughts

Keeping the above advice in mind won’t guarantee a smooth initial development phase, but will certainly help you getting up to speed faster, making more informed choices in the process.

Try to find a technical advisor if you can, preferably one that doesn’t send an invoice at the end of the month. Software development is hard, especially if you don’t have any experience.

Don’t forget to actually enjoy the process, because creating something beautiful from thin air is just magic.

Be a well-rounded software engineer

Wed, 22 May 2013 22:00:00 +0200

During a recent IM conversation I made a statement about probably being able to adopt any mainstream programming language or framework in a few days; I don’t care about the specific tech per se. I initially felt like a douche, but I quickly realized that this statement reflected what has been bothering me about my industry colleagues the last few months.

Don’t label yourself

A lot of my peers identify themselves by the technology stack they are using. Their profiles state they are “PHP programmers” or “Java developers”, or whatever programming language they are comfortable with.

Describing yourself by a technology is certainly a valid way of presenting yourself professionally. Your job probably requires you to spend a lot of time with that technology and you’re probably more familiar with that stack that 90% of the other things out there.

Describing yourself by a technology is also very limiting. You position yourself in a specific corner of the market, whether you want it or not. Specializing in itself is not a bad way of distinguishing yourself from the crowd, as long as it is a conscious decision and not because “it’s what you do.”

Tinker and learn

While our line of work allows us to tinker with new technologies in our spare time, there isn’t much use if you can’t apply the new concepts you’ve learned, outside of your weekend projects. In the end, you spend most of your time on your full-time job.

Getting outside of your comfort zone makes you more critical of your own work. It exposes you to paradigms that you might not encounter during your normal job. It allows you to accurately determine whether you are using the right tool for the right job and quickly make decisions about choosing a stack for your next project.

One thing I’ve noticed is that developers I look up to almost never associate themselves with a toolchain. The simply call themselves “software engineers”. If they do specialize, they are often an expert on the topic and are either heavily involved with the community. But they always tinker with other tech on the side.

You probably don’t want to work with a team that is resistant to change. While I’m not advocating for rewriting all your services in Go, you should definitely set aside a few hours to check out some esoteric tech over the weekend. You will be a better engineer for it.

Why you should get a degree in computer science

Sat, 16 Mar 2013 17:50:00 +0100

Helping out at a job fair at my old high school made me reflect on why I chose to get into IT. What’s the real value in getting a CS (related) degree when there are so many other subjects to study?

You will become a problem solver

Every single person I’ve met with a background in computer science has great analytical skill. They are able to decompose complicated problems into manageable smaller problems. This is an extremely valuable skill in a world where systems and processes are getting more and more complex.

Seeing how different sub-systems are connected isn’t just a technical skill, but can also applied at a higher organization level, such as business processes. It’s up to you to make problems tangible and communicate them well.

You can work anywhere

Want to work at Google? Or maybe at a hospital? Feel like working in government? Would you like to work in a large company or a small team? IT is everywhere and just about every organization is dying for highly trained IT professionals.

You are able to pick your own problem domain and apply your knowledge in just about every organization of your liking. It’s never a good choice to get into something for the money, but computers aren’t going anywhere soon.

You will learn concepts

Rather than learning tools, you’ll learn abstract concepts that form the foundations of different techniques or implementations. You will follow a course on object-oriented programming, not on Java. Java is merely a vehicle to get these concepts across.

These concepts allow you to easily pick up a new tool and start using it. You will not be an expert on a tool when you get your degree, but you will be able to pick up any tool and grasp 80% of the tool’s concepts within hours.

This isn’t just about programming

There are amazing CS students that are lousy programmers. Computer science is about models, logic, system architecture and so much more. While most CS students are pretty good at writing code, there are plenty who aren’t. Like any other skill it takes time and dedication to get to a certain level.

When you talk about IT in the broad sense, there are even more situations in which you don’t need to be a programming expert, but it most certainly helps.

You can create anything

One of the things that still amazes me is what you can do with a $600 computer. There are only a few professions that allow you to try things with so little expenses. Imagine being a civil engineer; there is no way you can build a big project on your own dime.

Most of the tools you will be using are available for little money, or no money at all. Some of the biggest IT companies were started in dorm rooms or dark attics.

The field is changing

I’ve seen a change in the kind of people that enroll in computer science in the last three years. I see a large variety of people and less stereotypical CS majors. IT is losing its negative stigma and that’s a welcome thing.

If you’re already in IT, please take the time to tell people about what your job involves. I was genuinely surprised how little kids know about our profession and it’s time to educate them.

Disclaimer: I’m not actually a CS major, but took a lot of courses that are included in the CS curriculum. I know the field, I know the people.

Tips for attending professional events

Sun, 17 Feb 2013 22:00:00 +0100

Professional events come in all shapes and sizes. From local meet-ups to launch parties and conferences. Here’s my simple plan to getting the most out of these different events.

Set your objectives

Without a goal it’s hard to evaluate your performance. Make sure you get your objectives straight before you get to the event. In some cases, these objectives might have been decided for you (i.e. your boss sends you).

You can go to an event to build out existing relationships, meet new people or educate yourself. Make sure your objectives are appropriate for the event you’re planning to attend.

Be courteous

Being courteous is especially important when attending smaller events Even though this is not required, I always bring a small gift for the host. This doesn’t have to be super original – if often bring a cheap bottle of wine – but it’s a good gesture.

Always greet your host when arriving and before you leave. This might be tough at bigger events, but again, it’s a good way of showing your appreciation.

Don’t keep you host busy for too long though; there are plenty of other people they have to attend to. Briefly thank them, congratulate them on the occasion and ask where your mutual acquaintances are at.

Let’s mingle

It’s a good rule to first catch up with the people you know. I like to catch up with existing connections for the following reasons:

I prefer building strong, long-lasting relationships with people rather than a lot of superficial ones. Because I do a lot of remote work, these parties are often one of the few opportunities to talk face-to-face with the people I work with.
These people will probably introduce you to other people, which is always better than walking up to a random stranger.

When you finished talking to your exiting connections it’s time to mingle. This often the hardest part of the evening, at least for me. Identifying people to talk to can be really tough, but it depends on the crowd. There are a few simple heuristics to recognize people you might want to approach.

Loners; the easiest to recognize. Most of the time these people are either waiting for someone to return or just finished another conversation.
Bored people; often found in larger groups. They either don’t really pay attention to the conversation or have a hard time participating. The latter category is harder to spot, but bored people often start looking at other things rather the people they are trying to converse with.
Your “own people”; as I wrote earlier, picking a techie from a crowd isn’t that hard. It’s easier to talk to people with common interests and really hard to converse with people you don’t have anything in common with. These people are probably really easy to recognize too.

When you’ve finished your conversation, don’t be afraid to tell you’re moving on to a next group. Don’t tell your conversation partner you’ll get back to them later when you’re not planning on doing so.

Post event

If your objective was to meet new people, you’re not done yet. I like to follow up with people by sending them an email with links/projects we’ve talked about. By sending them an email, you’re now in their most used communication system – their inbox.

Don’t be that guy that “connects” with everyone on LinkedIn the next morning. I personally don’t carry business cards and I’ve noticed fewer and fewer people do. If you can’t remember my name, our conversation probably wasn’t very interesting.

In 90% of the cases, you can easily find the email address of the person you’re looking for by searching for their name and company. Use your Google-fu.

It’s a skill

Some people seem to be natural at these things, but they probably went to a lot of events to get to this point. Evaluate what went good and what not. Ask friends or co-workers if you’re having difficulty with certain things.

As with everything it takes a lot of practice to master a skill. I certainly still have a long way to go.

This isn't rocket science

Sat, 26 Jan 2013 22:00:00 +0100

It isn’t hard to pick a techie from a crowd. A gentle reminder how to never judge a book by its cover.

An elderly lady approached me while I was waiting for my bus. We had a brief conversation about the cold weather and her reason for getting down to the station; she was there to get some information about a trip she had planned for tomorrow.

I let here get into the bus when it arrived and she sat in the single seat near the front of the bus, next to the driver. Before I sat down she turned around and told me I should sit at the opposite side of the aisle if I wanted to sit near the heater. “Well, thanks for the reminder”, I thought.

While the bus driver pulled away she brought up the subject of keyboard shortcuts in Microsoft Word. She discussed using Ctrl + U to underline text, Crtl + I to set the text in italics, etcetera. At this point my interest piqued. The bus driver admitted to never using these shortcuts, but promised her he would look into this some day; this was clearly a productivity booster.

At this point I was thinking she must have really enjoyed the computer course at the community center.

She continued the conversation by talking about Photoshop. Whether he had used Photoshop before? He had, but only occasionally. She collaborated about cropping photos, adding curves and whatnot. Again, the bus driver promised her he should look into this stuff a bit more.

After she concluded her explanation about Photoshop she continued with Microsoft Access and finally she started talking about how she used to program in Lotus Notes and how it always messed up her projects because of some weird space bug.

At this point the bus reached my stop. Before I got off I walked over and asked whether she used to be a computer programmer or something. “No, not really… but I used to work at NASA”.

Don’t be fooled, some things are not what they appear to be.

Another year without taking incoming calls

Sun, 30 Dec 2012 18:00:00 +0100

Last year marks the second year in my slow time lifestyle. No texts, no phone calls or push notifications interfering when I’m doing something else.

About two years ago I read both Timothy Ferriss’ ”The 4-Hour Workweek” as well as ”Rework” by the guys at 37signals. Both these books promote a new way of working, or better put, a more efficient way of working. Our lives are full of digital distractions, which all try to steal away our attention when we really need to do something else.

Instead of just reading and agreeing, I decided to follow up on the advice and silenced my gadgets. My phone doesn’t sound nor vibrate when someone calls, texts or tries to contact me in any way. My emails doesn’t get pushed to my phone and are only downloaded at my command.

The slow time philosophy

There are very little things that require immediate action, yet there are plenty of people who think their task or communication is more important than what you’re doing. This can be your boss or a friend. Most of the time they don’t even realize their communication is a disturbance.

As someone who needs some time to get into my flow, theses disturbances are both annoying and counter productive. Each interruption requires me to get into my zone again. By letting me getting back to you later, you allow me to get more stuff done, in less time.

Asynchronous communication is what you’re looking for. Text, email, IM, group chats and voicemail. Scheduling phone calls is another option, since it allows you to communicate on your own terms. You can even introduce library rules at your office.

Additionally, I love not being disturbed when not working. I really hated my phone calling for attention when I was having a good conversation or when watching a good movie. Don’t be a slave to your smartphone or computer.

Reactions

I’ve noticed that people have started calling me less in the past year. Instead they text or email me. When I give someone my phone number, I simply tell them they should try to email me first. They often end up calling anyway, but switch to email/text when I don’t answer after trying multiple times.

Some people questioned my so-called ‘experiment’ and wondered whether someone could function in such a connected society. Others supported my quest for more productivity and someone even sent me a funny comic.

These simple ways of reducing distractions and disturbances has fundamentally changed how I work. This doesn’t mean I don’t have a Twitter client installed, but it’s probably not running when I’m working on something complicated.

If you’re looking for New Year’s resolutions, give the slow time lifestyle a try.

Why Square will be huge

Mon, 17 Dec 2012 22:00:00 +0100

When Square started out as a way to accept credit card payments, it marketed itself as a tool for small business. Now even Starbucks is accepting Square. Amazing when you realize the company is barely 2 years old.

The industry

Payments and banking are notoriously hard industries to get into, but seemingly worthwhile because of its enormous volume. There are lots of interesting companies and developments in this space. Every single one with a different angle on how we should transfer money from a to b.

BitCoin and associated startups try to bring anonymous and independent payments to the masses. Dwolla tries to bring wire transfers to the US and Simple is trying to lure customers with its clear and customer-friendly service. Visa, AmEx and PayPal try to get a hold on the mobile payments markets, without much luck.

The story

Square initially focussed on making it possible for anyone to accept credit card payments. From the local gallery owner down the street, to your buddy selling a nice vintage couch. A noble cause and seemingly not too threatening for traditional credit card companies; they were focussing on small business.

Surprise, surprise, a lot of little transactions make up a lot of transactions altogether. How much exactly? About $10 billion annually. This may not seem like much, but remember who Square’s customers are? Small businesses. These are the users who are able to switch out their payment provider in a heartbeat. These are the people who will serve as advocates for your product.

As the icing on the cake, Square released their accompanying Register iPad app, which functions as a point of sale system. Not only does it provide the basic functionality of a register, but it allows customers to put purchases on a tab and pay with their name. At this point Square has created a superior checkout process virtually unrivaled in the industry.

Last week Square launched gift cards, which can be created for every store that accepts Square and can be gifted to everyone with an email address. These gift cards are basically Like buttons for the real world. New people are introduced to Square and merchants get additional business.

The lesson

The simple lesson that can be learned here is that you shouldn’t just iterate your product development, but also your market development. Square did a great job at establishing a user base among merchants, followed by their user base among customers.

Let’s not forget that Square was founded by Jack Dorsey, co-founder of Twitter. It’s impossible to say where Square would have been without Jack and his resources, but it’s fair to say that Square is going to be huge.

The rise and fall of web APIs

Thu, 22 Nov 2012 17:50:00 +0100

Ever since its inception, Twitter has been the poster child of the web mashups. You might even argue that Twitter was the catalyst behind the whole web API movement.

Social drives engagement, engagement brings in advertising revenue. Or at least that was the plan.

Now that the pressure is on, it’s time to tighten the reins. That’s not an excuse to leave developers in the dark, but it’s a reasonable decision from a business perspective (or maybe not). But, when you compare the Twitter API to others, it’s easy to see how fortunate we’ve been.

You can use tweets for offline analysis, promotional activities and develop games on top of it. Once you dive in the terms of service for the different APIs, you quickly realize how limited their use really is (without some sort of opaque partnership program).

Who owns what

These limitations bring up another question; who really owns what? Can a company x forbid company y to pull out a user’s data with their explicit permission? Is company x just providing an infrastructure for the data of the or is it adding some value?

Of course it depends. Posting a photo on Flickr is an interesting example. I would own the rights to the picture, but what about the comments? Flickr definitely adds value by providing a cozy community where people can comment on my photos, but what if I just want to get my photo out?

Company interests

Protecting your interests as a company and maintaining a competitive advantage over your potential competitors is difficult. Determining whether a company adds value other than providing the infrastructure isn’t a practical way to approach this problem.

Instead companies should be listening to their developers and decide on a case-to-case basis what is allowed and what is not. This would be a great job for developer advocates. Business really won’t mind paying for access to these APIs, as long as their concerns are heard and they can get the data out they need.

What is next?

The debate on open data and distributed social networks has been heating up in the past few months. It will be interesting to see whether the general public feels like migrating to a more open social network.

My money is on micro-standards. Their light-weight markup make them extremely easy to implement in a distributed fashion (your personal website!), but aggregation is a problem that still has to be tackled.

Co-founders: Being remote

Thu, 08 Nov 2012 22:00:00 +0100

Some people will tell you that starting a company with someone is like getting married. I was lucky enough to be approached by Dana and together we started hacking on our project; Skouti.

Our situation isn’t like the typical startup, or at least not as TechCrunch likes you to believe. We don’t have fancy offices, which is OK. All we need is a laptop, an internet connection and a good chair if possible. Neither do we work on Skouti 12 hours a day. We’re both in university and both maintain a healthy freelance business to pay our bills. Dana and I don’t even live near each other and consequently, only meet a few times a year.

The bad

So is all this a real problem when you’re moonlighting your project? Not separately, but together they do form quite a challenge for different reasons.

Progress is slow. When you’re juggling so many things, you often neglect the thing that has the least immediate impact. In my case, this is often Skouti.
Thinking long term is hard. Statistically, the chance that we get any substantial monetary reward out of this is pretty low. We would have had a great time, but that doesn’t pay the bills.
Keeping up motivation is difficult. Especially when you’re not physically in the same space. We mostly remedied this by scheduling a weekly Skype call and talk about things on our mind. Not always purely professional, but also personal stuff that is going on, so we’re aware of each other’s schedule.

So how can all this be countered? Well, to be honest, it can’t. At least not for the full 100%. Over the past months we’ve found ways to minimize the problems above, but ideally we would have a central office space, where we can work on Skouti full-time.

Schedule hack days

Dana and I tend to take the day off and meet at a central coworking space and work on Skouti for the entire day. These are the most productive days you’ll ever have. You will be able to make decisions quickly and have the ease of just walking over to someone’s computer and see what he/she is talking about.

Alternatively you can schedule a few hours or half a day and work together on your project, over Skype or IM. While not as good as the physical hack days, you still get the warm fuzzy feeling of working together and you can easily ask for the other person’s input.

Keep communicating

This may sound incredibly obvious, but when you only see your co-founder a few times a year and you’ve been busy working on other projects, there really are times when you drop the ball on this one (at least we did!). As I mentioned earlier, weekly Skype calls help immensely. Even if you’re not discussing your startup. Dana and I often share and comment on each other’s client work (unless we signed a NDA, of course).

We also email each other motivational articles. This can be something serious from the Economist, or the latest YouTube hype. It’s okay to talk about some multimillion dollar exist, even if you don’t plan on ever selling your company. Keep the dream alive. If you’re using a version control system to manage your code (which of course you do!), subscribe to the activity feed. You’ll quickly feel guilty when your buddy is working her/his ass off while you’re slacking.

Breaking the cycle

It’s highly unlikely that the schedules and current motivation of you and your co-founders line up. Yet it’s extremely important to make sure they do. Keep building that hype with your partners. Keep each other excited about your project (and other things!). That is when the magic happens.

I’m incredibly proud of the progress we’ve made in the last months and can’t wait to show our work to the world.