The GMU

Two Great Guys, One Great Team



Clients

The GMU Client Cloud


Our Business Model

  1. Software Contractor Vendor PO
  2. Corporate Contract & NDA
  3. Hourly Billing Only
  4. Flexible Hours
  5. Sub Contract Clause Preferred
  6. Technical Support Expenses

In addition:

  1. We are Linux/Python contractors.
  2. We fill contract hire roles with the addition that we are a team of two.
  3. Flexible hours means there is no obligation of ensuring forty-hours of work per week. We work the hours required.
  4. We prefer to be engaged with a company contract that includes a sub-contracting clause.
  5. We are generalists and require specialized technical support from time-to-time. This means we need to reach out to companies like Redhat or Oracle via per-incident technical support of sub-contracting.
  6. We have a network of sub-contractors we work with from time-to-time.


Our Business Scope

As you are thinking of engaging our services then understanding the scope business we focus on is essential.

The GMU is a software development company for software that is built to last using a software principle of "Test & Hand off". Our philosophy of "Test & Hand Off" means we provide a quality product, fully documented, with automated build & test that supports clean separation rather than target an open-ended income.

  1. Linux
  2. Open Source Development Environment
  3. The GMU laptops
  4. Software Development Life-Cycle
  5. Test & Hand Off
  6. Remote Work
  7. Independent Projects
  8. Turnkey Projects
  9. Defined Requirements

Out Of Scope

  1. Cloud PaaS Platforms
  2. Google Angular / Facebook React web applications

The cloud can be used as a straight up replacement for stand-alone servers. We can support these kind of cloud implementations because a virtual machine hosted locally or in the cloud differs only in administration.


Software Design Discussion

The current state of software design has been cleaved into two halves:

  • Public Web: move fast and break things.
  • Everything Else: software development life-cycle.

As the "Software Principles" Venn diagram below shows these two approaches overlapp. Confusion happens when developers mix-and-match the principles when they shouldn't.


Software Principles Venn Diagram

A "software development life-cycle" guiding principle works best for fixed environments. For example, a corporation's enterprise web site for its employees. Employees work everyday with a regular demand. Employees are added at a deliberate pace and software capacity can be planned. Another example of fixed environment is software designed to control hardware equipment. In our last gig at Intrexon our software was designed to construct synthetic DNA by controlling robots. Further, lab equipment in the science industry is a custom collection of various pieces of equipment from different hardware vendors. Information needs to flow between these machines and this is called LIMS, lab information management systems.

We here at The GMU are quality minded, we focus on software intended to last. The "move fast and break things" principle is antithetical to producing quality up front via testing. We take on projects that meant to stand the test of time. If your needs are for what we call "write once, run once" then we are probably not an ideal fit. While we can take over existing projects, we still expect a release cycle and expected maintenance mode where where we hand off the project to your existing team. This hand off includes robust test automation and documentation.

A "move fast and break things" guiding principle works best in the cloud where the life-time of everything is ephemeral. In layman's term this means that the OS and application are installed on demand. Imagine if every time you opened your laptop then you would install Windows 10, install all the applications, and then start web browsing. This is PaaS, Platform as a Service. The benefit to this "move fast and break things" approach is that the entire server can be reverted to a previous version and so breaking things means more than application bugs. Got a software update problem? No problem, just launch a previous server instantly. Computers have gotten so fast that deploying an entire server can happen in seconds. The PaaS design provides opportunities to easily overcome operating system misconfigurations, conflicting software package versions, application misconfiguration as well as application bugs. Further, the PaaS design enables infinite scale out where as demand increases then a new server can be instantly deployed. In the bad old days we had to over provision where one had to buy capacity up front. If we anticipated a maximum usage of one million requests per second then we had to buy and maintain that capacity from day one. The PaaS revolution allows capacity to scale as needed, even as real-time usage waxes and wanes. As server demand increases then new servers are instantly deployed and conversely as server demand decreases servers are instantly destroyed. This approach is essential when using cloud server providers like Amazon that price servers by metering usage. Every second a PaaS server is running in the Amazon cloud then that server is incurring a cost.