Hacked accounts, identity theft, security breaches. Security compromise is no longer a question of “if” but a question of “when.” With companies hoarding personal information for marketing, the payload of a successful data breach becomes increasingly more valuable to follow up attacks of individuals. Identity theft leveraging stolen information is typical after a large data breach. This is even more valuable if passwords are involved and attackers are more easily able to gain access to other accounts of yours for proving your identity.

Data Breaches

The elephant in the room. These are occurring more and more with companies that aren’t security first oriented. Startups and established and trusted businesses are both at risk and often victims of data breaches. They occur so often it’s hard to keep track and are often left undiscovered for several years. What can an individual consumer do to prevent these breaches? Practically speaking… nothing. You could decide to not use these businesses, but let’s face it, that is rather inconvenient and practically impossible unless you want to completely remove yourself from the internet. Even physical devices such as card skimmers are used to steal financial information. So unless you want to deal solely in cash, hold no money in a bank, and completely relieve yourself from the internet, you are prone to data breaches.

Take Precautions

There are tools to help protect yourself! For identifying yourself as part of a data breach, you could sign up for the completely free “Have I Been Pwned” website (that’s pronounced “Have I Been Owned“) to be notified if the information you provide is involved in a data breach. They also have a password checker to determine if the password you use has been identified in a breach. These are two very useful tools for determining which data breaches you are involved in and what information of yours may be subject to compromise. I use this service for all of my email accounts and have also added this website’s domain as an added precaution. It’s completely free and Troy Hunt is very active in its development. I strongly urge you to check it out, even if just to see if your account was involved in any of their identified data breaches. Spoiler alert: it is, especially if you have an account, like me, with any of these companies:

  1. Adobe
  2. LinkedIn
  3. Dropbox
  4. Evite
  6. Bitly
  7. Elance
  8. MyFitnessPal
  10. Apollo
  11. Evony
  12. Houzz
  13. NextGenUpdate
  14. ShareThis
  15. Zomato
  16. FlashFlashRevolution
  17. Neteller
  18. and another 2,844 data breaches my accounts have been involved in

Some of these don’t seem familiar to me (, ShareThis, Neteller, and Apollo), but upon further investigation, these are services other sites use for processing. This becomes more of a Privacy Policy fine print issue in that I never knew until a breach was published that another site used these for data processing. More interesting is that at least one breach was a Chinese company (NetEase) that I’ve never used and, through the breach disclosure, other victims have indicated the same!

Because of this data processing issue, and the fact nobody reads privacy policies (did you read mine?), a data breach of one of these services has a much larger amount of data and a much larger payoff for hackers. To combat this, you should never reuse a password, ever. If you currently have that one, easy-to-remember, password you use for all of your sites, you are not in the minority. You can also see if your password has been compromised if you search for it at Have I Been Pwned’s Password Search. It’s astonishing to me that the password “password” has been involved in  3,730,471 breach records at the time of writing this article. Over 35 gigabytes of related breach record data can be downloaded for this password alone. Password reuse is contagion for your accounts. If you use a password that has been breached, you should assume your account is breached and reset all accounts that use the password immediately. I’ve searched through my super-hard-to-guess, personal-to-me passwords and 3 of them were already breached. I then spent the better part of 2 hours changing passwords.

Password Management

These 2 hours had me wondering if there was a better way than remembering which sites I have logins for and what those logins even are. Enter LastPass. LastPass is a free password manager that handles creating and storing all of your passwords. If you’ve used your browser to remember your usernames and passwords for all your sites, LastPass does the same thing, but using secure methods. Your browser stores all of your usernames and passwords in plain text. What that means, is that anyone who has access to your computer can steal your usernames and passwords. It also means if your computer is infected with a virus or malware, that can also steal your usernames and passwords stored by your browser. Plain text password storage is equivalent to writing down your passwords on a sticky note attached to your computer. It’s highly insecure and easily stolen.

LastPass requires a single strong master password (or better yet, a passphrase!). This password encrypts your passwords and sites all in one single block of data known as a “blob.” There is no way to tell what sites you have passwords for or what the passwords are. The encrypted data is stored on LastPass‘ servers with no way of decrypting it unless you know your master password. You cannot recover your master password. Your master password cannot be stolen unless you store it insecurely yourself (in plain text on your computer, for example). You do have a hint you can use in the case you did forget your master password and there are a few options for recovery if you completely forget it (which I have on two occasions).

Getting set up on LastPass can be a bit cumbersome, but there is a password import utility that will import all of your website and password information saved within your browser into LastPass. This is a great first step in securing your online accounts. Once imported, you can disable password storing in your browser an leverage the LastPass browser extension to auto-fill, auto-save, and auto-update your passwords. When you create a new account on a website, LastPass gives you the option of creating a new randomly generated password for the site. This makes keeping strong and unique passwords for each site a breeze. I typically start at a high number of characters (~100) and reduce it if the website requires a shorter maximum password. The longer the password the more cryptographically secure it is. LastPass also provides the options to include numbers and symbols and/or to make the password human pronounceable (i.e.: a pass phrase).

Once you have all of your passwords migrated to LastPass, this tool provides a Security Challenge where it will take all of your passwords and run some tests against them. It checks to see how many are reused, how strong they are, if they have been involved in a known data breach, and if they should be changed based on their age in LastPass. The fewer the problems, the higher the Security Challenge score. Ideally, you would want 100% but that isn’t practical all the time.

Wrap Up

So, you might be a bit alarmed by all of this. You might even be overwhelmed. Security takes vigilance and persistence, but it also takes some time. If you’re sitting there using password for all of your sites and you’ve found it to be involved on thousands of breaches, don’t fret. You’ve identified that you have a password hygiene problem so now you can fix it. Head on over to LastPass or any other password manager you feel comfortable with and start cleaning up the mess. Take it one step at a time and soon you will have a strong grasp on your account security. You are not alone! Myself, I have a current Security Challenge score of 51% which is pretty garbage if you ask me, seems like I have some password hygiene to take care of!


Hypermedia as the Engine of Application State. Sounds fancy. It pretty much is. HATEOAS is a REST constraint where the state of the entity is transferred as well as what a consumer can do with that entity. It’s REST on steroids as it enables truly stateless distributed services that can scale without worrying about consumers.

In HATEOAS, the actions available for an entity are transferred with that entity. Take, for example, a traditional REST entity of a shopping cart:

<br>{<br>     "id": 11883,<br>     "total": "$10.00",<br>}<br>

In the traditional REST architecture strategy, a consumer would have to have logic to determine if it can add items to a cart, update cart item quantities, remove an item from the cart, purchase the items in the cart, save items from the cart for later purchase, etc. It would also need to know where to go to for each of these actions. This type of logic is intrinsic to a RESTful consumer application. Knowledge of how the REST API must be interpreted and developed prior to use.

Take the same shopping cart example and apply it to the HATEOAS API Design strategy:

<br>{<br>     "id": 11883,<br>     "total": "$25.00",<br>     "items":[{<br>          "id": 73,<br>          "name": "coffee",<br>          "price": "$10.00"<br>          "qty":2<br>     },{<br>           "id": 42,<br>          "name": "creamer",<br>          "price": "$5.00"<br>          "qty":1          <br>     }<br>     ],<br>     "links": [{<br>          "href": "",<br>          "rel": "item",<br>          "type":"DELETE"<br>     }, {<br>          "href": "",<br>          "rel": "item",<br>          "type":"DELETE"<br>     },{<br>           "href": "",<br>           "rel": "purchase",<br>           "type":"POST" <br>     }, {<br>          "href": "",<br>          "rel": "item",<br>          "type":" PUT"<br>     }, {<br>           "href": "",<br>           "rel": "item",<br>          "type":"PUT"<br>     },{<br>          "href": "",<br>          "rel": "cart",<br>          "type":"DELETE"<br>     },{<br>          "href": "",<br>          "rel": "qty",<br>          "type":"PUT"<br>     }, {<br>          "href": "",<br>          "rel": "qty",<br>          "type":"PUT"<br>     }]<br>}<br>

This example shows how you could (poorly) structure your links attributes to handle any steps available when perusing your cart. You could update the quantity of your items, clear your cart, remove a single item, purchase all items, save items for later, etc. The point of this example is that the consumer doesn’t need to worry about the actual API calls. The consumer can just be aware of the entity types and leverage the actions available for any given resource. This example defines links as described in RFC5988. You could really use any type of defined links as long as it describes the actions that are available to the resource.


As you can see, this type of architecture strategy allows consumers to become more dynamic. A consuming application would only need to be made aware of an originating call to the API to retrieve entities with link attributes that determine what is available to the consuming application.

With HATEOAS, scaling web services becomes rather trivial. If multiple domains are used during scaling, the links attribute simply lists whichever are available and the consuming application can blindly follow these links to take whatever appropriate actions they provide.

Using HATEOAS is particularly useful in workflow management for multi-step processes. If you think of HATEOAS in terms of a workflow diagram, the linksattribute becomes more clear. Each step in a workflow diagram can be a resource guided by the links provided by that resource.

The Value of Design

In the projects I’ve worked on, about half of them skipped any sort of design phase. This typically lead to unmanageable code a few months into the project with no discernible way to backtrack or quickly change architecture. While each project could benefit from their own postmortem on their design phase (or lack thereof), I’m going to focus on the commonalities between projects that had some form of design phase and projects that did not. Feel free to use this as a guide for your future projects.

The Good

A design phase can be beneficial for any project. It provides a moment to think about the solution and how the architecture for it can be developed modularly with reusability and maintainability in mind. Do not underestimate this phase! This is where deep thought occurs in how the system should be developed and how the system is intended to be used. APIs are designed during this phase which will determine how the system interacts with itself and other services. A good design at this phase results in cheaper development and cheaper maintenance.

While design is important, there is a diminishing return on investment in design. The more time spent on designing a system without implementation, the less valuable it becomes. Development teams should be cognizant of their time spent designing and, after a high level design, begin designing the first thing to implement. Iterative designing alongside developing results in a flexible work plan and a flexible architecture or API design. The idea with a lightweight and iterative design process is that future design improvements build on top of or extend the existing design. Any future work that requires a re-write highlights the lack of understanding of the original requirements or a design that is inflexible. A good barometer of when a design has “enough” value is when the software engineers understand the system they are about to begin developing.

In addition to understanding a system before implementing it, design provides a blueprint for enabling test-driven development. Designed APIs may have tests written against the expected behavior of the implemented logic before any logic is actually implemented. This type of testing leads to clean and clear requirements alongside understanding of how the system should operate after implementation.

The Bad

So, why don’t teams design? The perceived cost to design in terms of time (and we all know time equals money) may not generally seem to be all that valuable to project management. Why spend time thinking about the project when you can just jump right in and start making it? This perceived cost saving measure of cutting or severely reducing design time isn’t necessarily tangible to project managers. Project managers typically care about actions that move the needle forward. Design does not move the needle forward — it moves the needle faster.

Because design is cut from the process, a lot of time is spent re-implementing, re-working, or refactoring code. Developers often code themselves into a proverbial corner and find the system that they have build is not easily adaptable to a new feature that needs implementation. This new feature requires refactoring the existing code. This refactoring doesn’t have an opportunity for a design phase. And the implemented feature is later refactored again when some other new feature needs implementation. This is a vicious cycle that often becomes the status quo and the team’s productivity quickly plummets (not to mention morale).

Furthermore, with all of this rewriting and refactoring, the system and the team’s understanding of this system, are not guaranteed. The system is a hodgepodge of various hacks and quick fixes that it is effectively held together by “magic.” I’ve been on a project where this “magic” ended up preventing new features and we ended up tracing the logical flows. This lead us to discover that there was a nasty bug in logical flow that wasn’t expected and would not have otherwise been discovered. What was worse was that we couldn’t fix this bug without declaring technical bankruptcy and reworking the architecture to achieve the intended (and expected) results.

The Ugly

Let’s talk about the ugly truth of any code base, regardless of good, bad, or no design: technical debt. Ward Cunningham coined this term and it is an analogy to treating deficiencies in a software product as a loan that accrues interest. The longer a deficiency persists in a system, the more technical debt it accrues. A project can accumulate so much technical debt that forward progress is no longer possible and the project must declare technical bankruptcy. This bankruptcy results in either a failed project, or a rewrite of part or the whole system. Martin Fowler has a lovely article that describes this concept in wonderful detail.

Following this same analogy, consider design a down-payment on a project. Sure, you can certainly start working on a project without a design, but you will quickly start accruing technical debt and that debt will accrue faster. Do yourself a favor and work in a design whenever you need to refactor something and before you start working on the code! Coding without a plan is what typically gets a software team stuck in technical bankruptcy. Don’t repeat what got you there when you dig yourself out!

Wrap up

Knowing all of this, it’s easy to see the value in design. Building a system without a plan has large hidden costs. Refactoring without a plan compounds these costs. When you don’t have a design phase at all you are essentially earmarking money to burn down the road with more time re-developing parts of your system until you can’t move that needle at all.

Hiring Good Developers

Hiring Good Developers

Hiring software engineers is easy, hiring good software engineers is hard. Due to the nature of software engineering, there is no clear or objective way to measure the skills of an engineer. Companies try to determine skill based on questions and online skills assessments. The problem with this approach is that it doesn’t highlight quality skills of a good software engineer.

Online Skills Tests

Online skills assessments typically provide a question to a software engineer and a time limit to answer this question. Sites like HackerRank provide a great platform for these types of tests. The engineer is generally not allowed to look up information (on the honor system) and the question doesn’t typically relate to the work the developer will be doing if hired. This type of skills assessment is reminiscent of college exams and doesn’t typically allow the creative freedoms normal working environments grant.


I’ve been part of take home assignments and have developed hiring processes that include a take home assignment with an accompanying code review. The intention is to allow the developer to showcase their engineering talents then showcase soft skills (like group presentations) and their ability to accept feedback and explain their work. While this isn’t fool-proof and doesn’t provide a subjective solution to the hiring process, it does showcase talent. The code review is meant to also prevent an unskilled engineer from copying another solution. Unfortunately, this too has some drawbacks: the developers that spend the most time on a take home project have a better quality product.


Limiting time on homework projects is more of a suggestion as it is not enforced and favors those who spend more time on the project. This isn’t possible for some who have a full time job and family to tend to. Skills assessment tests favor those who regularly practice assessment tests and isn’t necessarily a good measure of their skill set in the work environment. Perhaps a different solution is necessary. Perhaps a timed, “open book” live coding exercise is better. All input could be tracked through the web console to get an idea of the developer’s thought process behind their work and could be played back (maybe at 10x speed) to watch it all unfold. This type of format would relieve the candidate of time related stress while also allowing the creative process of the candidate to shine. Sure, there are some trade offs to this approach, but isn’t solving problems why we all got into this business? This seems to be the hardest to solve.

Building a Product Vision

Building a Product Vision

Developing software under deadlines is hard. When I start projects I often have a problem to solve in mind and that’s it. It takes some effort and genuine thinking to come up with a solution to that problem. Part of that solution is having a vision. Without that, how do you know which direction to go? Developing a solution without a vision is like attempting to navigate a cave without light. If you haven’t been caving (or spelunking) before, it’s pitch black in there without a light. So much so that you literally cannot see your hand in front of your face and you don’t know which direction you are facing. If you don’t know which direction you are facing when developing a solution, how do you know where you are going?


Each project I undertake a leadership role in, I seek as much information as possible from the client. Defining your project’s vision is 90% asking the right questions and 10% of thinking about the solution. If you’re asking the right questions the solution will appear as if it’s emerging from some magical mist like a unicorn in the early morning sunrise. The best resource I’ve found for defining your vision is Roman Pichler’s Product Vision Board.

Product vision board
Your best resource for defining your vision.

So what questions should you ask? That’s a great question! While it does largely rely on what field your project is in and your client’s preferred method of communication, there are a few questions almost all project leads should ask and they are all right on the product vision board:

  1. What is your purpose for creating the product?
  2. Which positive change should it bring about?
  3. Which market or market segment does the product address?
  4. Who are the target customers and users?
  5. What problem does the product solve?
  6. Which benefit does it provide?
  7. What product is it?
  8. What makes it stand out?
  9. Is it feasible to develop the product?
  10. How is the product going to benefit the company?
  11. What are the business goals?

Once you can answer these questions, some sort of vision of your solution should come to mind. You should start recognizing that unicorn. You’re also in a great place as you’ve validated your product and have a clear path forward. In addition to this, you could also answer a few more questions about your vision to get clear insight into the current market and what it would take to make your product profitable. This part is optional and definitely recommended if you plan to sell your product. These questions are included in the extended Product Vision Board.

  1. Who are your main competitors?
  2. What are their strengths and weaknesses?
  3. How can you monetize your product and generate revenues?
  4. What are the main cost factors to develop, market, sell, and service the product?
  5. How will you market and sell your product?
  6. Do the channels exist today?

I highly recommend answering these questions if you plan on marketing and subsequently selling your product as it will position you favorably when it comes time to sell your product.