The Seven Righteous Fights: Extensibility

This is the third fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

What can you do that would make your product more extensible, more configurable, easier to put into the ecosystem you are trying to serve? I always explain APIs as a sort of Lego connector between a given piece of software or data, and anything else someone chooses to stick on it. Make your APIs standard and DOCUMENT THEM WELL.

Lego_ball

You can connect anything to this.

What makes you so sure this API will always be internal?

On a recent contract, we started to create APIs for our internal services. We bodged them together in a really ugly way, with names that only made sense internally, based on dead products we didn’t release. I argued that it would be better to build them correctly, but obviously I didn’t argue enough, and when I left, they were having to rewrite the whole API call structure because an external client had requested access it.

Don’t make future-you mad.

Make future-you happy by designing your product to consume APIs. That way when you get a sudden request to provide APIs for a customer, you’ll know that they work because you’ve used them yourself.


This blog post is part 3 of my Seven Fights series. You can hear me give this talk TOMORROW at The Lead Developer in London (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

 

How to write a lightning talk

This week I was at Write/Speak/Code, a conference designed to teach technical women how to excel in other parts of their careers. It was amazing, soul-filling, and sometimes painfully honest.

I was asked to mentor a group of nine women for Speak Day. We had a couple hours for them to write and deliver lightning talks. A lightning talk is a very short talk, usually about 5 minutes long. They are an excellent way to get a taste of conference speaking without needing to do a full talk proposal. They’re the gateway drug of standing on the big stage with a mic.

Here is what I asked my class to do:

Pick a topic

Lightning talks are not limited to strictly technical topics. I have seen amazing lightning talks on printing presses, homebrewing, arduino, and Minecraft, as well as more conventional topics.

I always pick talk topics based on something I’m angry about. I find that’s a good place for me to find the energy to drive a speaking project forward.

Create your title slide

Creating your title slide helps you break the fear of a blank page.

Title page for a technical talk

Title page for a technical talk

Always include your name. I also strongly recommend you include a way to get in touch with you, if someone has questions or job offers later. In this example, I used my Twitter handle. I also gave people a hashtag that they could use to tweet about the talk. This is an innovation I’ve been trying to spread for about 6 months and it appears to be working. Yay! It makes it much easier to Storify tweets about the talk if there is a unique hashtag.

I’ve added my handle and the hashtag to all my master pages, so that they appear on every slide. It’s really annoying when you go to tweet someone’s amazing insight and it’s 20 slides after their intro and you can’t remember their handle.

Write your conclusion

Yes, really, this is the next step. If you only have 5 minutes, you must have a punchy conclusion. If you write it first, then all your other writing will lead to it.

Write your thesis

What are you angry about? What do you want to prove? What do you want to show people? What do you want to teach them? This is essentially the same as the thesis paragraph in your five paragraph essay that you wrote in elementary school. Make sure your thesis is short. A long thesis means you have chosen too complicated a topic and you’ll run over time. I think my favorite thesis/title from this group was “Passwords Are Terrible”.

Thesis Example: Teaching children to wash dishes is like writing automation scripts.

Write the antithesis

Unlike the five paragraph essay format, we’re not doing three paragraphs of supporting detail. Instead, I suggest using thesis-anithesis-synthesis. In this model, your thesis is followed by objections that could be made to it, or problems that are likely to occur in implementation.

Antithesis example: Children are less reliable than computers, and they also don’t have good chron scheduling.

Write the synthesis

Reconciling your thesis and antithesis is deeply satisfying. You can bring them together in the common areas, and explain how you would get around the problems brought up in the antithesis section. Writing this section is like creating your own plot twist.

Synthesis example: Although both automation and teaching children to wash dishes have initial startup costs higher than the task, investing in them saves you work in the long run. You still need to kick off the process manually, though.

Add the pictures

For me, images on slides are a mnemonic. The picture reminds me of the next thing I was going to say, much more than my words do. The pictures you add will be appropriate to your personality, your topic, and your audience. The reason we do this close to the end is because it’s better to have your ideas solid before you get lost in the weeds of image search. I entertained my group by having them search for pictures of Pusheen:

Pusheen, a very tubby grey stylized cartoon cat, is bouncing and spinning its tail.

Pusheen is an adorabale animated cat gif

Practice

I always practice my talks first by muttering through the slides, and then by asking people I trust to give me feedback. There is not always time to do this for lightning talks, but try to practice it if you can. You MUST come in under time, because people will cut you off. There is no mercy for lightning talks that run long.

Logistics

  • All the lightning talks I’m used to are given from a single computer run by the conference. You send a link or file of your slides and it’s not run on your computer.
  • You may or may not have a presentation remote to advance your slides. Some conferences only let you have one slide, or don’t use slides at all. That’s ok, you can still write out the talk, you just can’t get distracted looking up corgi pictures.
  • You will have a handheld mic, if anything. It takes too much time to set up the other kinds.

Finally

Have fun! Lightning talks a great way to get used to speaking in front of crowds without having the full-on nervousness. Nothing can go THAT wrong in five minutes.

Here is my great group!

A group of 10 women sitting around a cluster of tables. They have laptops in front of them and have turned to smile at the camera.

Breakout Group 4 works on lightning talks at Write/Speak/Code 2016

The Seven Righteous Fights: Security

This is the second fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Contrary to what you may have heard, the internet is not actually a series of tubes connected by guys in ski masks. There are bad actors out there, but your product probably won’t attract them right away.

But there will come a time where you have to send out a really embarrassing email to your clients because your waffle-buddies app has been breached and everyone’s syrup preferences have been posted to a pastebin somewhere.

Waffle and syrup

Syrup and waffle in gorgeous light.

It’s expensive in terms of reputation and in terms of productivity, because everything has to stop while you solve the problem.

Security is probably the place where it would be easiest to over-optimize your product without a lot of benefit, because it takes a lot of experience to do security correctly, and that experience does not come cheaply. It would be ridiculous to do a full security audit on an app that doesn’t handle money or personal identification before it is even out of beta.

That said, I think you can think MORE securely than the next person.

How can I be more secure?

  1.  Understand IN YOUR HEART the differences between authorization, authentication, and security. Being confused about it makes you more likely to build something with a serious flaw.
  2. Leave yourself room to perform encryption. It’s probably never a bad idea to start from HTTPS (on ALL the pages). It’s not going to hurt you to use SSL, even between your own services.
  3. Understand what kind of data needs to be protected, and what people can figure out from “innocuous metadata”. Every piece of data you collect increases the threat surface for you and your user.

    HIPAA and other protective agreements shelter obvious things like your social security number, but also less obvious things, like your birth year if you’re over 90. That’s because it is shockingly easy to figure out who someone is with enough bits of “meaningless” data.

Keep less stuff

Plan to delete users and delete data. Even if you flip a bit that disables logins, if you’re keeping the data, you’re the problem.

We grow and change. Eventually we end up dragging a lifetime of data, like Marley’s chains in A Christmas Carol. They are the chains we forged in life, and they never go away.

I want data jubilee.

Don’t reinvent the wheel

Use someone else’s auth* engine. You don’t have to reinvent the wheel, and you probably shouldn’t. This is especially true if you are in a social space or an enterprise space. The IT people installing your system would really rather you just used Active Directory or SAML or OpenID (but really AD) instead of lovingly hand-crafting your own.

Stop saying that word!

(the word is “secure”)

Imagine that a pack of rabid lawyers are waiting to gnaw on you anytime you claim something false. False things can include “we secure your data”.

Conclusion

You don’t have to build something entirely secure now – that’s prohibitively expensive. But do leave yourself the hooks and plans to add security before you have a major incident.


This blog post is part 2 of my Seven Fights series. You can hear me give this talk at The Lead Developer in London next week (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Localization

This is the first fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Are you ever planning on selling this to someone in another country? Or someone who doesn’t speak your company’s primary language?

I’ll tell you right now: Yes, you are.

There’s a big wide world out there, full of people who don’t speak American-flavored English. If you want to reach them and get their money, you’re going to need to speak to them in their language.

Unless you are working for 18F, everyone has the potential to sell their software overseas. Maybe not this release. Maybe not next release. But soon, and you had better plan for it. Hire a localization consultant for a couple days at the beginning of your project and ask them what they wish people would think of in advance. These are the ones I know of:

  • All labels referenced from a list.
  • No words besides the company name embedded in logos.
  • Extended character support baked in.

Hard-coded labels are going to make it very expensive to localize your user interface. Instead of a “normally expensive” translator to look at your labels file, you’ll need to find someone who can use your interface framework, and you will need to do that for every language you want to use. At this point, most people do the work of pulling the labels into a file for reference, but wouldn’t it be great to save that step?

If you have words in your logo, even things like “Professional” or “Edition”, that should get localized along with everything else. That means redrawing/re-rendering the logo for each language, and burning a bunch of artist time.

Extended character support is important so that you can render all the languages you’re going to use, but it is vital that everyone be able to enter their name, the way they spell it. It is extremely alienating to not be able to identify yourself accurately. Don’t make your users feel like you don’t respect their identity at the very beginning of your relationship.

Be careful of:

  • Explanatory videos
  • Humor
  • Fixed-width elements

Videos provide a powerful way to deliver tutorials on a complicated interface. However, even a user who could translate their way through written instructions may have trouble with the speed of video narration.

Humor translates very strangely. It’s very culturally-based and dependent on things like tone, register, and word choice, things that vary with language and culture. A very good (expensive) translator could translate humor for you, but it’s probably best to leave it alone.

Fixed-width interface elements are going to make you cry when you localize. If you want to see why, take a line of English and use Google Translate to take it to German.

English

German

File Datei
Settings Einstellungen
Edit Bearbeiten
History Geschichte
Log in Einloggen

Different languages take up different amounts of space!

If you use a few best practices while you are coding up your initial product, you will save yourself thousands and thousands of dollars when you go to release internationally. Localization estimation is complicated, but in this English to German translation example, the lowest price I found was 12 cents a word, and the fastest an average translator can work is about 2000 words a day. If you could translate 200 interface words in one referenced file, or 2000 repeated and hard-coded words across dozens of pages, which would you rather pay for?


This blog post is part 1 of my Seven Fights series. You can hear me give this talk at The Lead Developer in London next week (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).