Think of your software team like two astronauts that are launched into space. Sure, there are only two people who are actually on the mission. They are the ones that gave up their everyday lives to head out to space. They are the ones on the news and chatted about over water coolers. They are obviously the main attraction. But without their team? They could never have gotten off the ground. Nor could they stay alive while rocketing along in space.

Life is much the same for the Software Engineer. (Except for fame, fortune, and the getting-to-go-to-space part…)

At EduSource, we believe that teamwork is the best way (and really, the only right way) to build custom software. Obviously, your software engineers (and apprentice software engineers) are the main attraction. They are the ones that are full-time, sitting at computers, writing code for your project.

But there is a whole team of people that help them with specialized tasks as needed.

Some software companies use time & materials contracts, and on invoices, you’ll see line entries for some or all of these positions. At EduSource, we do things differently. We charge you one fee for the whole team, and we’ll take care of who’s needed when. If a project needs a bunch of attention from a high-dollar architect, it will get that attention, but without an additional cost to you.

But who, exactly, makes up that team? Here’s a breakdown.

Software Engineer

 

What’s the role: This is the person (or people) that actually program your software. They will be following our EduSource software process to program your custom software project.

What makes them qualified: Generally, a computer science or engineering degree from a four-year college or university. At EduSource, we believe that a mix of formal education, hands-on experience, and intentional training make the best software engineers.

Why do you want it: Well, without the software engineer, there isn’t any software. If you are purchasing custom software, you better hope there are software engineers (also called developers, devs, or programmers) on the project.

How much time will they spend: Software engineers will use up a bulk of the time – at least 2 hours per EduPoint, and often more.

 

Apprentice Software Engineer

What’s the role: EduSource apprentices are generally students working on a computer science (or related) degree. Apprentices work for us for up to two years, full-time during the summers and part-time remotely from their colleges during the school year. During their second summers with us, Apprentices help train their newer counterparts.

What makes them qualified: EduSource has developed relationships with local colleges and universities, which helps us find the best apprentices for our team. We had more than 80 applications for our 2018 team. With that many applicants, we are able to hire the best.

Why do you want them: Why wouldn’t you? Apprentices have strong educational backgrounds and have been trained in our software process. Youth brings two key things (one negative and one positive): inexperience and innovation. We counter the inexperience through extreme code review. Every line of code written at EduSource goes through seven different lenses of review. Apprentices meet weekly with coaches to look over frequent code-review mistakes. But what we’re most amazed by? Their innovation. Bringing in fresh eyes helps us look past the solution that’s been used in the past and toward brand-new ideas. Our apprentice program is how we stay fresh and relevant with new technologies and solutions. Another bonus? Adding them to your development team raises production significantly without significant investment.

How much time will they spend? It depends. Sometimes apprentices help full-time software engineers, and sometimes they can do the work themselves. It completely depends on how complicated the functionality is.

 

Tester / Quality Engineer

What’s the role: Way before we hand functionality over to you, you better believe we’re going to test it internally. That’s what our Quality Engineers do. When the dev team has completed the first round of programming, User Stories are assigned to a tester, who make sure they accomplish the acceptance criteria we laid out when we wrote the story.

What makes them qualified: A desire to break things and an extreme attention to detail. Technology prowess is important here, too.

Why do you want it: You absolutely want a tester on your team, because they are skilled at finding the weird little things that come up with new software. Will they catch every single one? No. That’s why we have you check it again after they finish. But they will find a lot of small bugs before they ever get into your hands.

How much time will they spend: It completely depends on complexity. Testing can be anywhere from 15 minutes to an hour or more per EduPoint. If the tester finds something they don’t like, the User Story will go back to the developer for rework.

 

Software Architect

What’s the role: Having a software architect’s eyes on every project is what enables us to rely so heavily on youth. This is the expert who makes high-level design choices and dictates technical and coding standards. Basically, the architect is going to help your team determine the best way to build your project, and close off any doors that don’t make sense.

What makes them qualified: The biggest difference between a software engineer and a software architect? Lots of experience. You can’t just decide to become a software architect, because the years and years of trial and error in software building are what makes someone qualified. At EduSource, software architects have more than 15 years of high-level programming experience.

Why do you want them: When an architect isn’t involved in your project, you’re running a huge, expensive risk. Sure, you can work with a lower cost shop that skips this important step. But by having an architect’s eyes on the project, you’re ensuring that someone with plenty of experience is making sure the path is the right one BEFORE the programming actually starts. Software projects are well-known for being behind schedule (and over budget), often because new developers are coming on and off the project, or it just doesn’t have a solid structure map in the first place. By having an architect set the direction from the beginning, you’re giving your software the best chance of success.

How much time will they spend? At the beginning of your project (or each phase, if it’s large enough to have them), your Software Architect will sit down with your team to help plan things out. Your team will then present that proposed solution to a group of software engineers (we call this Tech Forum), who will offer insight and suggestions. This initial planning will take around 5 hours, depending on the size and complexity of your project. After this initial planning, the architect will be available on an as-needed basis for questions, updates, and redirects.

 

Client Relationship Manager

What’s the role: Your Client Relationship Manager (CRM) is basically a translator. Even though we work hard to hire very “human” developers, there are still times when the less-techy of us sit around with our mouths open, having no idea what they are chattering on about. We don’t want that for you, so we created the CRM position. The CRM will keep you up to date, in English, on exactly what is happening with your project through weekly meetings and other communication.

What makes them qualified: It takes a special kind of person to be able to bridge the tech gap, so we look for people with a lot of experience in a tech environment and strong communication skills.

Why do you want them: This will be your go-to person at EduSource. You’ll get weekly updates with any problems or questions. And he/she will schedule occasional demos and meetings to keep things on track.

How much time will they spend? Between meetings, answering your questions via email or phone, and relaying info from you on to the dev teams, your CRM spends an average of 2-4 hours per week on most projects. Of course, there are weeks when they spend way more, and weeks when things are pretty quiet.

 

Business Analyst

What’s the role: A Business Analyst (BA) is imperative in the software process, because he/she works with stakeholders to define business needs and extract requirements for what must be delivered. In English? The BA takes information about your software needs and breaks it into small chunks (or User Stories) for the developers to work on. And gives the developers specific instructions (acceptance criteria) about what the story must do to be considered “complete.”

What makes them qualified: Attention to details and a deep understanding of how software works. This is a highly technical position, but usually not a programmer. We want a slightly bigger-picture thinker for this job, but also one that can focus on the intricacies of what a button should do when it’s pushed.

Why do you want them: When you don’t have a BA working on a project, developers don’t know what they are aiming for. This is also the person developers come to with questions. They have the big picture in mind.

How much time will they spend? It’s Any work that gets done is first defined by a BA. So for any User Story, a BA is going to spend at least 15-20 minutes defining the work and acceptance criteria. And then the BA will be available for any follow-up questions.

 

Project Manager

What’s the role: A Project Manager (PM) makes sure the project stays on track. He/she is the person who will make sure your team is meeting DLA metrics, which measure things like how effective they are being or if they are on schedule. The PM is also in charge of resourcing. If a project is getting behind he/she will add resources to the team as needed.

What makes them qualified: An in-depth understanding of how to develop software and an iron-fist regarding deadlines and delivery schedules. This is the person EduSource holds accountable for keeping projects on track.

Why do you want them: It’s pretty obvious – if you want software completed on time and on budget, you need someone who is very specifically looking at those things daily for each project.

How much time will they spend? As long as things are on-track, a PM shouldn’t spend more than an hour or two per week for each project. When things get behind, the PM’s job gets more intense, and the PM will get very involved in getting things back on track.

Just like our lonely astronauts shooting for the moon, we often think of our software engineers in a vacuum. But they can’t complete your software without their team around them, any more than astronauts can get to space without their booster engineer.