Apollo Group Evaluates MongoDB

The Apollo Group is the company behind University of Phoenix. It recently conducted a thorough evaluation of MongoDB and published the results. The paper is included below, but Apollo Group outlined the following keys for successfully deploying to MongoDB:

  • The key to MongoDB performance is thoughtful data model design.
  • Design the deployment to match data usage.
  • MongoDB is a great match for cloud-based, on-premise, and hybrid deployments.
  • MongoDB has excellent availability.
  • Latency between different Amazon EC2 Availability Zones within the same EC2 Region is very low.
  • At 85% CPU utilization, the behavior of MongoDB changes, and performance levels off.

Overall, this is a great approach to follow when you’re evaluating new technology, not just MongoDB.


Joining a Distributed Team

With software development talent harder to come by in hotspots like Silicon Valley, companies are looking for talent wherever they can find it. Distributed development teams are becoming more common. As a developer, joining an established distributed team can be a challenge. Aside from the technical challenges, such as learning an existing code base and processes, you also have to socialize with your new team.

When I joined Nodeable‚Äôs distributed development team a few months ago, the team was already in place and processes were defined. I had to quickly adapt to developers that had worked together for over a year and start providing value immediately. These are some of the things I did to acclimate to my new team. You may find these helpful if you’re in a similar position.

Start Early

A few weeks before starting, I learned about the development and deployment processes. This allowed me to ramp up on any tools I may not have been familiar with. There were very few in this case, but the opportunity was there to close any gaps.

Additionally, I started reviewing the bug database. This provided two advantages. First, I could figure out how the team used Jira. Is it just used for bugs and immediate work items, or for broader road map items as well? The second advantage was less obvious. From looking at the bug database, the history of the team as apparent. What areas of the application underwent significant change or were abandoned? Which ideas looked promising but were later dropped due to changing priorities or pivot? This doesn’t seem important but it can give you insight into how your new team works. And when you’re not seeing them in person everyday, every piece of data is helpful.

Avoid Cost Center Work

This point isn’t isolated to distributed teams, but I’ve found the impact of working on cost center stuff to be greater when working remotely. When you join a new team, distributed or not, you want to avoid working on tasks not directly related to the product road map and/or a profit center. Cost center tasks are things like chasing obscure bugs, anything related to devops, or writing unit tests. (Sorry, but unit testing is a massive cost center.) While you can’t avoid cost center work all the time, and you shouldn’t, it’s better to avoid it when starting in a new position. It’s demotivating and helps to erode that crucial honeymoon phase at a new company.

 

Copyright © Nick Heudecker

Built on Notes Blog Core
Powered by WordPress