[App Review] Questions – Ask and Answer

The App is simply called “Questions”.

A friend of mine contacted me from the Silicon Valley.

He is working on an old/new way to get answers from the interweb : humans.

We all know Google, Naver Q&A and Yahoo! Q&A. But this is an experience you need to try.

I was busy and not very reactive to his requests to try it. But it’s interesting. Just a beginning. But with huge implications.

The App is simply called “Questions – Ask and Answer“.

How it works

  • Ask a question : you record a short video asking something, give it a one work name and wait for answers
  • Answer a question : choose a title or a thumbnail that catched your attention and record a short video of you answering
  • For example : I asked “What is the best month to visit California?” and someone answered within 3 hours.

photo 5


What I like

  • Easy and very well adapted to a mobile experience. Would not imagined use this on desktop.
  • Nice to see the face of the people answering your. You can extract more information from facial expression than any textual response.
  • Fast answers
  • Lots of questions to answer
  • Quality of answers may vary but you can ask questions you would not think of trying to fit on Google keywords.
  • photo 2

What could be improved

  • Sometimes you don’t want to show your face, that’s one of the success of the Internet.
  • Level of questions and short time to answer makes it hard to see any profound answers or debates
  • Even for factual questions, it’s always faster to type on a search engine
  • UX and design is not perfect for the moment (dark theme), making the experience more awkward than necessary
  • Not a lot of users for the moment and no way to filter questions really.


They are just starting. But give it a try and tell me what you think.

There are a lot of interesting User Experience challenges here.


They Don’t Always Have To Use Your App

If your app is for a team of users, don’t focus on the app nor the users. Focus on not impeding their interactions. Don’t forget they can talk to each other and think on their own without your app !

If your app is for a team of users, don’t focus on the app nor the user. Focus on not impeding their interactions. Don’t forget they don’t need your app to talk together. They are already doing it. Worst : don’t try to replace live interaction with electronic processes. It’s best for them and cheaper for you.

It was a shiny day of July, the meeting was 3 hours long. The goal ? Prioritizing, specifying and poker planning the next sprint. We made the mistake of scheduling it right after a 8 hour meeting with our key users (sort of day-long presentation/feedback of our latest monthly release). Now we were embarking on the next sprint. We were exhausted and really focused on details.

Examining story after story, we were fighting to make them all fit in the sprint. First mistake.

Second mistake : focusing too much on each story at a time. Loosing the big picture.

The third mistake needs a little back story.

Our application’s goal is to help people who already work closely together to do so with a tablet. They already talk to each other, they are trained to work together. They work this way since 1933 at least.

The user stories were about helping the team leader to distribute roles in his crew. Simple in appearance…

It’s was a nightmare of story dependencies, complex vague specifications, really expensive features.

Why ? We forgot the people the leader has to manage are physically  in the room during the use of the feature. Hence all controls, feedback, error-prone specifications we were trying to establish were useless.

Simply by TALKING to each other, the users could work together. We forgot that since the begging. Focusing more and more on the new tool we were building, we forgot the primary human tool : talking.

We saved our velocity and the project budget. But the danger is still around. Don’t forget the most basic human skills instead of trying to replace them all in one app.

Your Best Developer Tool : An English Dictionary

If you can’t put a name on it, you don’t know what it is. An English dictionary is your best programming friend.

If you can’t put a name on it, you don’t know what it is

Peer programming with a lead developer on an important iOS project, I discovered a plain English dictionary or a thesaurus is my best friend.

You need it to name your objects, variables, classes, services, folders, …

It’s the best way to see if you understand what you do. Concepts you will implement must have their own special vocabulary.

For example, we were looking at a name for a model object. The object had to be a pre-filling container to build a more complete report. It had to be displayed on an UI to be filled, and to be opened and transferred via an URL. So it was used both as front and backend representation.

Well, we searched a name for 2 hours.

The reason it was so difficult was that :

  • the concept was too close from another object, but different
  • the concept was vague
  • the concept had too many faces or too many responsibilities

We tried :

  • ReportExcerpt (hard to pronounce for French speakers)
  • ReportSummary
  • ReportIndex
  • ReportPrefiilingModel

We finally settled for : ReportSkeleton.

Thank you Mac OS Dictionary App 😀 (by the way it’s waaaay faster than the Internet, try it)

And it’s even more important if your are not a native english speaker. Don’t use a translator from your language to English. Search an English dictionary. You’ll win one level of vagueness and indirection of your idea.


Software R&D : Stop Focusing On Technology

Some big companies have centralized development R&D. But sometimes, it’s simply not working.

Some big companies have centralized development R&D. But sometimes, it’s simply not working.


Start making developers better at choosing instead of choosing for them


Don’t misunderstand me (especialy you my dear colleagues who read this) : we need some kind of normalization in a company with a lot of different quality level developers. But if you focus on technological solutions you’ll risk to miss the point and make yourself useless. Especially on tight budget.

Do Less :

  1. Trying to produce One-Size-Fits-All-In-One-Inegrated-Frameworks
  2. Hiring intrusive consultants for a short term study
  3. Producing Out-of-the-real-world POCs (Proofs of Concepts)
  4. Listening to all exterior vendors that claim to have the best One-Tool-To-Rule-Them-All

Instead Start :

  1. Gathering common needs from different projects already in production or in the making
  2. Emulate innovation by offering a kind of Entreprise Github
  3. Best : go open source and participate to the real world solutions
  4. Organize as many education events as possible. It’s harder but cheaper than buying soon deprecated solutions.
  5. Create an internal StackOverflow to promote help between product departments that never speak together.
  6. Promote User Groups for both external (open source) tools and internals
  7. Look for the best practice, not the average one. For example promote and teach TDD and Continuous Integration.

What matters is not an all in one solution that will deprecate in 2 years, what matters is making the other average developers of your company better.

It’s about education, not technology. It’s not about methodologies, it’s about state of mind.


What Kind Of Lead Developer Are You ?

There are at least 2 kinds of Lead Developer. The Backup and The Coach. A leader is always someone making you progress in your craft. Either by teaching or by showing.

There are at least 2 kinds of Lead Developer. The Backup and The Coach. A leader is always someone making you progress in your craft. Either by teaching or by showing.

The Backup

He is working in the shadows. He is your safety net. Every commit, every unit test or method, he scrutinize it.

His goal is to soften the difference of levels between other developers. He is quiet and working on tasks you don’t see at first :

  • repairing or improving a unit test
  • reordering your files
  • answering your small questions
  • taking and applying merging decisions for your
  • making great utility classes and stacks to accelerate your work on the most visible part of your project

The difference with a simple developer is that he can explain what and why he is doing. Hence, you progress.

Each of his commit is to be looked at. Because they can and should change the way you code.

The Coach

He is spending more time with you than coding on his own. Peer programming with him (either as a pilot or a co-pilot) is a better than 2 months of school.

It can be frustrating for him, just like for the Backup leader; because he is more helping others to code than coding.

He is the guy you look after every time you start the architecture of a new user story. And you should. More visible he also have to be humble yet firm.

You Should Hire Both

They are complementary. There can be many leaders, not just one. And the time spent by the first must be used by the second to educate the team.

Both are the architects of the project, one by example the other by reputation.

I worked with a good combo on an iOS project. And it’s a joy to follow them, through the code, or in peer programming.

And you ? What kind of lead developers did you meet ?


If you still hang on to “features” you are not as Agile as you think

If you still speak about features, or plan to add another sprint to “finish” the backlog : you are not Agile.

On some Agile projects I’ve been working on I noticed an arch reality :

If you still speak about features, or plan to add another sprint to “finish” the backlog : you are not Agile.

One of the first warning I give a new client about Agile projects is the following : your backlog is not a magical whishlist. You can have :

  • sprints (event with fixed time frame)
  • a backlog
  • a board
  • a scrummaster
  • a product owner
  • a daily meeting
  • and so on

but if you still think the team will finish all your User Stories at  the end of the last sprint, you’re gonna have a bad time.


So Agile is a big scam, right?

No. Certainly not. It’s a reality call : if you don’t have enough money to build all you have in mind, you won’t.

And you know what ? It’s a good thing ! Features are not the goal of all this sprinting. It’s about VALUE.

Your backlog is not final. It’s a moving plan. It’s a goal. And User Stories are certainly not features. A US can be composed of many features. Or none sometimes (just a simple analog solution)

There will be delay and lag. Even in Agile of course. And the solution is not to do another sprint. It’s to cut down the number of features and start concentrate on what is really meaningful to users.

If you think I’m to vague start looking a the best product out there : less features but an immense value each time you use it.

Dismount what you already built !

Maintenance is a part of your software value. It has a cost, it represents a debt.

So some final word of advice :

Have some budget dedicated to dismount or erase some features. It increases software quality (with less code base) and increases its value (more stable, less feature creeped soft).




Translate your iOS app to Korean : a tip

While trying to add Korean support to the Wifinsite app, I ran in the following problem : the app stays in english. French was ok, but no Korea.

Actually you have to add 2 Korean languages : ko(korean) and ko-KR(South-Korea). Very disturbing.


PS/ Sorry for the short article. I’ll post a detailed tutorial if needed.


Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.

Here are 10 reasons why you, as a manager,  should care about unit tests. It’s a summary of this series of 12 articles on unit tests for managers. Continue reading “Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.”