Author: Oasis Digital

On-site is back – COVID-19 pandemic update

Last spring when the pandemic arrived, we quickly transitioned to 95% online operations, as detailed in our post at the time. Throughout, Oasis Digital has continued serving customers online/remotely, delivering results effectively albeit less conveniently. We have had no known workplace-spread illness.

Here is the United States, as of April 2021 the pandemic appears to be winding down quickly. Most of our team is vaccinated, our headquarters office is in full use, and client interest in on-site / in-person engagements has started to return.

Therefore, we are now scheduling on-site client engagements, of course with due care and precautions.

Our open-enrollment classes will gradually include in-person dates later in 2021.

(We are keenly aware that the pandemic is currently much worse in some other areas of the world.)

Full Stack Hiring – Apply Now

Update May 2021 – we hired 5+ developers in early 2021, and are now looking to hire 5+ more.

Oasis Digital is growing – maybe you should be on the team! We are again looking for more great developers. All the usual information is available on our careers page.

All the info is there of course, including a video with lots more about working here. Here are the key aspects:

  • The core of our team works at our headquarters in St. Louis MO – at least during non-pandemic times. But more of us also work around the USA (and a few around the world) on our customer projects.
  • We mostly hire full-time employees, with contractors for certain circumstances.
  • We hire at a wide range of levels; entry-level software developers eager to grow fast, through grizzled gurus who already have the deep understanding and experience our most critical customer needs.
  • No “take-home interview coding test”; rather we will program with you at the relevant stage of the hiring process to get to know each other, and see your abilities in action.
  • The most common key skill for new hires is Angular, React, or one of the other competing frameworks.
  • “Full stack” is best, though many new hires start in one layer of the stack (for example, in the browser, on the server) and learn the rest over time.
  • Please apply via our site linked above – that is machinery we use, resumes that arrive any other way tend to get lost.
  • Our hiring process is about the same as in this 2018 post.
  • Feel free to reach out by email (address at the lower right of our web site) and ask questions about the job, to figure out if you may want to apply.

Also, a bit about our philosophy of hiring:

  • Hiring is a marketing-like process, not a sales-like process. We aim to get the word out so that the right people find us.
  • Hiring is a collaborative process of looking for the best match, not a race or competition.
  • We hire people whose time is valuable, so we optimize for rapid assessment and understanding.

Blog posts can get stale. Our current hiring is always listed on our careers page!

Angular for Architects – preview/beta class, Jan 2021

First we worked for years on numerous enterprise Angular projects. Then we spent months organizing the knowledge of our experts. The result: Angular for Architects, now available from Oasis Digital.

This class is about both the coding aspects of Angular architecture, and also the decisions, patterns, costs, and constraints that drive architectural decisions.

Early access / Beta test class

To prepare and validate the curriculum for Angular for Architects, we are running a special beta-test version of the class. To show appreciation for attendees willing to jump in at this stage, the price is cut by half.

The first such Beta test is in January. Depending on how it goes we run a second “beta”, or proceed to standard pricing.

Who Should Attend?

  • Decision makers responsible for large or complex Angular projects
  • Angular tech leads and project managers
  • Application and system architects
  • Teams looking for a shared understanding of Angular architecture and practices

Oasis Digital developer hiring process

Candidates keep asking: what is the process to be hired at Oasis Digital as a software developer?

Our process is solid, realistic, and strikes a good balance between speed and depth. Yet merely knowing what the process is, isn’t much competitive advantage, there’s no reason to keep it secret. Good results flow from the execution, not the checklist.

As of 2018, here is the typical Oasis Digital hiring “workflow”; sometimes it varies for special cases, people with whom we already have a substantial connection. It’s best to think of this as a kind of “funnel”. At each stage, we are looking for signs that the candidate would perform well and be great addition to our team – and trying to show strong candidates that we offer them an opportunity to thrive.

  1. Initial contact or awareness. Perhaps they see a job post somewhere, or someone refers them to us. Ideally they have a chance to watch a short video about the job and about working at Oasis Digital.  Usually we receive a resume (via a tracking system, like everyone else – so that we don’t lose track of any). Of those, some catch our eye. Those move on to…
  2. We have an initial, short conversation/interview about the candidate’s experience, current situation, what they’re looking for in their next job, qualifications, etc. We have this conversations over a video chat, to provide the candidate the maximum “bandwidth” opportunity to make a good impression about these things. A portion of the candidates move on to…
  3. A longer discussion. This discussion again is ideally over a video chat, and often involves more than one of us at Oasis Digital. If the candidate already happens to be in St. Louis, sometimes we meet in our office or over lunch; but video chat is actually “good enough” even for local candidates, and that sometimes can be scheduled more easily or promptly. Of these candidates, a portion move on to…
  4. Our real interview with a software development candidate is to spend time coding together. Ideally this is in-person in our office; although for an out-of-town candidate it’s possible to do this over a screen sharing session. We try to spend at least an hour on this, sometimes several. Working on some code together is by far the most effective way to understand where a candidate is in their development mastery. It is much more effective, and faster, than the sort of “take-home sample programming assignment” that has become popular in recent years. If this goes well and we are favorably impressed, a candidate might move on to…
  5. A deeper, more traditional “HR style” interview, where we talk about the candidate’s experiences, strengths, weaknesses, goals, and so on in depth. Will the person  the person strengthen our team, and reinforce our values? Are our benefits and compensation attractive? Can an agreeable salary be worked out? If all that goes well, the final stage is…
  6. There is a background check process; our customers often require that developers with access to their materials have a clean background check. Assuming nothing negative pops up…
  7. Successful hire – onboarding begins.

From writing all that, wow, it sounds like a lot! In the best case, it can be executed in a few days of elapsed time, although usually there is not such a rush. Our process is intended to be a less onerous time commitment for everyone involved – yet still provide ample opportunity to get to know each other – compared to what some larger companies go through.

Update (2021):

For many positions we’ve streamlined and improved even further from the 2018 description above. Our process focuses on seeing candidates in action. We hire on demonstrable technical proficiency or potential, not on the ability to endure lengthy traditional interview questioning. The process:

  • Job post and informational video provide candidates information before interviewing.
  • Interview 1: discuss some code, and the candidate codes a bit. 30 minutes or less.
  • Interview 2: discuss more code, candidate codes more. Discuss the job more. 30-45 minutes.
  • For some roles or candidates, additional interviews are needed.
  • Offer, hire, start.
  • Onboarding, learning boost, and mentorship process begins.

(Of course there is variance on the length and use of the interviews, depending on details of each position.)

Software Product Quality at Oasis Digital

A long-studied topic

Decades ago, business guru Philip Crosby famously defined quality as “conformance to requirements”. This definition seems useful in software development only to the extent every aspect of the software has been comprehensively understood and written down – rarely the case in real projects.

Fewer decades ago, software and consulting guru Gerald Weinberg slightly less famously wrote that “Quality is value to some person” – an insight more applicable to our context here at Oasis Digital, consultants and developers of custom software products. (Incidentally, to gain dense insight into software development and other topics in well-written tidy packages, read Weinberg’s books.)

Still, to point out that quality is whatever someone (typically a paying customer) says it is, doesn’t help all that much with a problem we face regularly.

I want a high quality software product, but what does that mean?

At Oasis Digital, customers often come to us with a vision, or partial written requirements, for a software product or system. Around this essential kernel, there are numerous possibly-implied desires or requirements, many related to quality.

What should an organization (or person) want, if they generally want a good, high quality product? We think of the answer to this as the implied requirements for high-quality software.Recently the team here started gathering a list of quality attributes (special thanks to Paul Spears for kicking this off on a whiteboard for all to see). Here is our checklist of desirable attributes, requirements, meta-requirements, and other aspects of quality or otherwise “good” software.

Quality checklist

The software we work on most often has both server-side and web/tablet/mobile UI, so our checklist contains a somewhat broad mix of topic areas.

Functionality

  1. The software works “on the happy path”; it has all the specified desired features.
  2. The software handles numerous potential error conditions well; it fails gently, and visibly. It recovers, or fails clearly if it can’t.
  3. The software implements a workflow at least as friendly to users as envisioned; ideally even more so.
  4. The software augments, rather than consumes, human mental bandwidth while using it.
  5. The features are generally composable where appropriate. That is, when a pair or set of features are more valuable when used together, they can be used together and work as expected.
  6. The software conforms to legal or regulatory requirements to which the subject; achieving this often requires cooperation among developers, customer representatives, and sometimes experts in compliance. In some projects this may be a minor aspect, while in others it is a primary defining motivator.

Support and operations

  1. The software captures logs of events that go wrong (and generally also of things that go right); it does so in a manner suitable for aggregation and analysis, with generally well considered log levels, a machine-readable log format, and so on.
  2. The software has features suitable to help with support efforts; for example it shows what version of the software is in use, helpful error data is exposed (in log as well as, where possible, on screen) rather than discarded, etc.
  3. The software is operations-friendly. It has switches, features, or other attributes helpful for operations teams responsible for keeping the software working.
  4. The software does not forget facts to which it has been exposed; where technically feasible, it has an append-only, log-structured view of the world. This both supports debugging efforts and future not yet known requirements.

Appearance and behavior (UI/UX)

  1. The user interface conforms to some design system, its layout and appearance are not completely subjective and ad hoc, but follow some understood and well considered guidelines for appearance, layout, etc.
  2. Unless the software is either very large (with a large budget), or is an art piece (such as a game), it does not “go its own way” with an ad hoc design.
  3. The user interface is aesthetically pleasing, in the subjective sense. (To whom?)
  4. The user interface further has suitable animations or dynamic style behavior, suitable for its design system.
  5. The user interface is themeable; at least its colors, and possibly other aspects, can be adjusted to fit in coherently with other software that uses some defined color palette. The user interface code should therefore use appropriate color theme variables or similar mechanism, not be hardcoded to match a design system or ad hoc requests.
  6. The user interface is responsive; it makes reasonably good use of a wide range of screen sizes. It is not a fixed size for a single screen size, unless its target (embedded) deployment environment is similarly strictly limited.
  7. The user interface does not suffer the “keyhole problem”; when presenting the user with a significant amount of data, it makes good use of the display to show the user many options and useful context.  http://www.aristeia.com/TKP/draftPaper.pdf
  8. To the extent of the user interface presents data in tabular form, the tables presents numeric and text content with suitable alignment.
  9. The user interface features the variable contents (data) and more prominently than fixed labeling; a well-chosen design system generally will achieve this goal out-of-the-box.

Operating / human environment

(As of this writing, most of the software we work on has a web user interface, and that shows in this checklist.)

  1. The software supports all current browsers, and possibly (depending on target deployment environment) one or more obsolete browsers as needed.
  2. The software has good accessibility characteristics, including testing with a screen reader or similar assistive technology.
  3. The user interface visually scales well in response to user font size overrides; it does not attempt to block the user from changing the font size, and its layout remains usable across a range of font sizes.
  4. The user interface contrast levels (as supported by the design system) are high enough to pass accessibility testing.
  5. Color is used effectively to maximize the speed of comprehension; but no information is ever presented only in the form of color, so that the software remains workable for users who don’t perceive color fully.
  6. The software is reasonably compatible with its platforms internationalization capabilities; and if needed, has been (or can be) suitably localized.

Performance and throughput

  1. The software has been tested, and works acceptably, with a realistic date volume. It is often necessary to obtain or generate test data of configurable size to verify this need has been met.
  2. Performance characteristics in error handling characteristics have been considered jointly; so that an occasional error does not completely halt the throughput capabilities of the software. It is possible to move past or set aside a failure case and continue meeting throughput expectations in the case of occasional error.

Security

  1. The software is built on a platform or framework choices which have reasonably well considered security characteristics; the software cooperates with this platform in such a way to generally inherit those characteristics.

(Security could fill books, not one section of a single blog post. For a software product applied primarily to an internal, benign audience, the above is probably sufficient; but for software deployed to the open Internet, or in other cases where hostile actors are expected, appropriate much more substantial security design and implementation is needed.)

Development Process

  1. Intentionally chosen, considered process appropriate for the project
  2. Regular demos or other progress presentations to stakeholders
  3. Regular code review, before (not only after) code enters the mainline of development
  4. (of course many books could be and have been written on development process!)

Internal characteristics

It’s possible to write software which externally does everything it is required to do, but internally is a shambles. Some thinkers imagine that this is the timely and inexpensive way to create software. We have not found that to be the case. Rather, to achieve external quality without overwhelming cost, internal quality is vital. We strive to create reasonably good internal quality without being explicitly asked to do so. Internal quality characteristics often include:

  1. Consistent code style, applied automatically
  2. Linting, applied automatically
  3. Internal and cross project code reuse – general avoidance of duplication
  4. Architectural consistency across portions of a system
  5. Consistent use of suitable platform features; don’t reinvent the wheel, don’t blindly apply techniques from one platform to another

Making sense of Quality for a customer project

This list is long (and could grow much longer). Achieving these things may consume substantial time and effort. At the same time, software projects often arrive at our door already under schedule pressure. To manage this conundrum, we work with customers to consider this list as a default; a list of things that probably should be done, but which a customer might choose to skip some items for schedule or budget needs. For each aspect of quality, a certain amount of minimum attention is needed (and automatically applied by a high-quality software team), but beyond that there is a range of possibility subject to customer priority.

 

The Oasis Digital Spectrum of Services

In the early years of Oasis Digital, we offered exactly one service: outsourced software development contracting. Since then, we’ve expanded to a spectrum of related services. The result doesn’t fit in an “elevator pitch”, but it meets the needs of customers much better. Our “spectrum of services” will be more clear on our main website and elsewhere over time, but this blog post explains it as succinctly as we can. Ranked in approximate order from smallest to largest, we offer:

1) Free technical content

Our expert developers/trainers speak and write about relevant technical topics, and the results are almost always freely available: talks on our YouTube channel, posts on our blog, our twitter accounts, and so on. Further, we attend various conferences and are always happy to speak to people who come talk with us there.

2) Tickets to public classes

We teach on several technical topics, most prominently Angular Boot Camp. Class tickets are a great fit for an individual developer or small group, who can purchase, then attend online or in person around the US and occasionally around the world.

3) Private training classes

To train a whole team at once, we offer private classes, both online and in-person. Private classes can also easily be extended with add-on days of customized consulting and training, for customers looking for added value. Some customers engage us for a series of private classes.

4) Application assessment

An application assessment is a short consulting engagement (typically 1 week, with 1 or 2 of our experts) in which we meet with a new customer in-depth, to assess an application (or understand the vision of an application). The assessment includes a written report, and (if needed) a proposal for future recommended work.

5) Ongoing expert assistance

Oasis Digital can provide ongoing expert assistance, in a retainer-like arrangement. We regularly meet with your developers, to help with questions, issues, code review, design guidance, and implementation of key areas. We have different packages depending on how much assistance each month you need.

6) Agile product development

In an Agile development project, a Oasis Digital works with a customer on an iterative basis, prioritizing features (“stories”), responding to changes and guidance. Such a project is especially amenable when the product vision is established but feature needs are still evolving. An Agile project is straightforward to contract and price (based on the team size), and can start quickly then last as long as needed. We often begin Agile projects with Oasis Digital developers, then gradually integrate customer developers over time for an eventual handover. The project style is also well suited when Oasis Digital is joining an existing effort already in progress.

7) Scoped product development

In a scope product/project, the features needed are worked out in advance (a scoping effort might be part of an application assessment, for example) so that Oasis Digital can provide a price and schedule to achieve that known list of features and surrounding goals. This style of project is decidedly less agile (changes and additional features are generally implemented after successful delivery of the initial scope), but can also ultimately be more efficient – our experts are especially adept at skipping directly to a high quality approach, avoiding false starts and reducing rework during iteration.