Category Archives: Architecture

3 Trends about to take off – Part 1

alexa-small2017 is halfway over and while some of these trends started a few yeas ago I think we’re about to see a few of these really catch-on, and by catch-on, I mean go mainstream and get funded.

Over the next week I’m going to discuss these three trends in a little more details and provide some code or projects to help you get started!

Trend 1 - Alexa / Voice / AI Chat

What does user experience look like without a mouse & keyboard or easy to enter form fields? How do people talk to AI systems to solve problems? These systems can be through devices like Alexa or virtual systems like automated chatbots. Understanding psychology and human behavior become just as valuable as business knowledge when designing these systems. Because of this we will see new software architectures come into play that deal with these variations and have multiple and guided user flows.

Trend 2 – JS/UI Architecture

SPAs (Single Page Applications) built on frameworks like Angular and React changed the way we think about building software. But for the longest time it was code, code, code without much thought of how it’s going to scale, and how it’s going to be supported in the enterprise. These systems need to hang around and be maintainable for 10 years, refactoring your apps should not have to entail complete system rewrites. Having architectures for UIs that allow for modular building and refactoring are crucial for adoption of these technologies that change every 9 months.

Trend 3 – Augmented Reality

There’s more and more data about the world around us. Why not provide more ways for people to interact with this data? Why make everyone have to look something up on a browser or an app? Voice combined with computer vision begins to bridge this gap. Google Glass still might not be the right use case, but camera augmentation, heads-up displays in cars, smart kiosk and push voice will be where this begins to have application.

Don’t Use Frameworks

How many times have you heard that Framework fill_in_the_blank will save time and prevent developers from doing things their own way. Or Frameworks save time by eliminating some of the redundant work on application development.

These might be true, but how many times has a the same framework been proposed for creating a 5 page website, or using an entire logging framework to write the results of one job to a text file, when no one ever reads that log…

So I will create the following rules for when using a Framework is OK, if it does not pass this test, roll your own.

  1. Does the framework configuration/ training take the same time or longer than the coding of said functionality? If yes, don’t use a framework.
  2. Is application connecting to multiple tables for Create, Read, Update and Delete transactions? If yes, perhaps some type of database framework is needed, that could be it, don’t install an elephant when you need a mouse.
  3. Does application require standardization for reuse/resale or for multiple programmers of varying skill? If yes, use a framework unless it contradicts with rules 1 and 2.
  4. Is application or library going to be reused and distributed open source? To facilitate the code and adoption it’s often easier to create when people are already use to the patterns and coding of an application, in this case, unless it contradicts with the rules above, use a framework.

Use Simple, Not Loose, Coding Standards

Many times when starting a project you will get a request for some documentation on coding standards for the project. Why? So you don’t get a bunch of coding cowboys and end up with an application that looks completely different from source file to source file.

On the other hand, if you end up with “standards” that are too strict, you may have well just built a code generator to write all the code for you because the standards will often be more verbose than most application code.

Below are ten simple standards that can replace every coding standards manual ever written.

  1. Don’t Repeat Yourself (DRY). If you find your code redundant and doing the same things, refactor before it’s too late.
  2. When making any design decision, ask yourself, what’s the easiest or simplest to explain? Pick the easiest or simplest option.
  3. When making any design coding decision, ask yourself, what’s more lines of code? Pick the least lines option.
  4. Don’t use a framework unless you really need a framework. You need a framework if it’s not more lines of code or configuration, it does not complicate the application, and it does not add redundancy to your code.
  5. All code should be testable because it’s not complete until it’s tested.
  6. Design by behavior, and don’t put two behaviors in the same class or method.
  7. Use simple rules for categorizing behavior: UI or Client, Business Logic, Data  Centric.
  8. Use interfaces to define behavior, use child classes to inherit functionality, use them only if you need to share behavior or functionality, remember POJOs are your friend.
  9. Don’t complicate things by adding a “Go4 Pattern”, XML, external configuration, or other gold plating techniques for some nice to have minor enhancement to configurability or some other “ility”. Only use if the result is less lines of code or simpler to explain.
  10. Commit early and often to a repository and don’t check in untested code to the repository.