When designing an application, separate UI code from the code that makes your application “do things”—what is traditionally called “business logic”. Make sure an airtight interface separates your business logic from your UI.

Taken to its logical end, business logic code should exist in its own library or framework, and your UI app links against it.

Separating your business logic this way allows you to repurpose it in other apps, create command-line versions of your app (useful for scripting), refactor it without changing your UI, or overhaul your UI without introducing errors into your app’s core logic.

Even if you never refactor or repurpose your code, this separation acts as an organizational tool while you design your app. Follow this pattern and your app will likely be more maintainable.

• #FridayDevAdvice

When writing multi-platform code, conditionalize code on features, not platforms. For example, if you can’t use instruction set X on platform A, conditionalize on HAS_FEATURE_X instead of IS_PLATFORM_A.

Then, create one file in which you map platforms to features. That way you can easily add new platforms and switch features on and off without going through all your code.

#if IS_PLATFORM_A
  #define HAS_FEATURE_X 0
  #define HAS_FEATURE_Y 1
#elif IS_PLATFORM_B
  #define HAS_FEATURE_X 1
  #define HAS_FEATURE_Y 0
#else
  // Default behavior, should work on all platforms
  #define HAS_FEATURE_X 0
  #define HAS_FEATURE_Y 0
#endif

Remember, if you have a final #else clause, it should only contain platform-independent code that will work on any platform, perhaps with less optimization.

• #FridayDevAdvice

Let’s talk about personal values and what they mean for a software developer.

Have you put some serious thought about which kind of software projects you will accept, and more importantly, which kinds you will reject, beyond financial considerations?

Can you articulate the values you are willing to project through your work? How much personal responsibility will you bear if your product is used to harm or coerce, rather than empower or protect?

Software used to guide a missile has consequences. So does software used to profile applicants for potential jobs, or help people live a healthier life. Will you accept the moral consequences of your code? Will you accept both praise and blame for how your software is used?

What unintended consequences might there be for the code you write? What will you do to mitigate them?

Find your bright red lines before you accept your next project. If you’re like me, you’ll sleep better at night.

• #FridayDevAdvice

If your app offers UI, a crucial but difficult task before you is UI testing. While you can get away with occasional, informal testing when you first begin, the challenge of UI testing will grow very quickly.

Use a combination of automated and manual testing. Although automated testing will catch the most obvious regressions, subtle problems such as animation and polish issues are much harder to detect automatically.

Typically, larger products will be tested using a three-pronged approach:

• Automated regression testing
• Manual regression testing of known flows
• Living-on coverage, where stakeholders use unreleased software daily

To me, what makes UI testing especially challenging is the fact that it involves unpredictable, fickle, human users. You must allow for subjective appraisal of your UI during testing. Build it into your plans.

• #FridayDevAdvice

Tinker. Play. Be curious about something in your spare time, no matter how silly or insignificant. Amuse yourself with children’s toys. Finger-paint. Make silly apps. That’s how you stay inspired.

• #FridayDevAdvice