“What is custom software?”
“Why is the sky blue?”
“Is custom software right for me?”
“How many developers does it take to screw in a lightbulb?”
We answer all these questions and more on a regular basis. Wondering about our company and what we can do for you? You’ve come to the right place!
Our tagline at EduSource is Humanizing Technology, and we take it seriously. The process of developing custom software is a unique journey—one that can be mysterious and a little scary for clients. Our goal is to make this process accessible and understandable. We don’t want this experience to be frustrating or scary—you’re getting custom software to help your business flourish! It should be exciting. We are continually thinking through new ways to help you as the client understand and enjoy this journey. These are some steps we follow to make sure you’re not only getting the software you need, but also the experience to go with it.
We ask a ton of questions—our goal is to learn as much about your business as possible before we start. The more we discover, the better we will be at planning your project.
We don’t want to miss a single detail. So after we discover, we put a plan together, then we come back and ask you more questions. We want to make sure we get everything exactly right in the plan so the development comes out right the first time.
This whole process of software development is complicated. We totally get it. So we make sure to communicate with you early, clearly, and often. It’s our goal to make sure you feel informed and comfortable with the project at every point.
We know you can’t be at our office checking on the project 24/7. But we want to make sure your voice is heard in the process as much as possible. So we have a client advocate whose job is to make sure we’re keeping your perspective at the forefront as we develop.
Want to know more? Check out this blog post about our client journey.
At EduSource, we like to compare building software to building a custom home (it’s a little easier to communicate in terms of plumbing and doorways than it is to talk about SPROCs and queries). When you decide to build a custom home, you pay an architect to put the plan together. She’s very skilled and she probably charges a lot of money an hour. But it’s worth the expense to get the plan right up front. Then you pay a builder to take the plan and make it real. The builder is probably working on three or four different houses at once, and he hires subcontractors to do the actual work of building while he oversees the construction of all the projects.
That’s what we do at EduSource. We have senior-level software engineers who architect projects and oversee them. But there is a lot of actual computer coding that they don’t do. That’s because it’s work that doesn’t need their expertise. So who are our subcontractors? We call them apprentices.
We hire computer science students during their sophomore through senior years of college to work with us on software development. We call it an apprenticeship because they’re working directly with our senior and mid-level software developers, learning as they work. They get individualized coaching and attention, and are able to experience a real work environment working on real-life projects. It’s a benefit to them, and it’s a benefit to you. By hiring apprentices to do the less-complicated coding work on your project and keeping the high-cost senior level employees working on the more highly complicated aspects, you’ll see a 25% savings on your software’s price tag. It’s all about giving the right people the right work, and it benefits everyone.
That’s the high-level view. Want the details? Here they are!
The short answer: Yes. We can deliver your software on time.
How do we do that?
Through a process we call Daily Layered Accountability (DLA). DLA is a way of checking in daily with teams to see how on-track we are with projects according to various metrics.
DLA meetings start at 9 a.m. sharp, and team members are expected to be on time. Teams meet with their Business Analyst (BA) and go over their project boards. The classification is simple: if teams have two or fewer tasks past due, the project is green, but if they have more, the project goes red. Red isn’t always bad—often, we can quickly get back on track by putting in a few extra hours, getting help that’s needed, or just working harder. But it’s an early indicator of a problem that shows us that a redirect is needed.
Once we’ve categorized the issues, we talk about their causes and how we can fix them, then figure out what the goals are moving forward.
These DLA meetings generally last less than 15 minutes. It’s been amazingly worth it to us to take the time for them. You could walk into our office right now and know immediately if our teams are on track or not. The public nature of the boards holds teams accountable to the rest of the company and to clients, who occasionally visit the office. DLA has taken us from being a typical “late” software shop to being a unicorn: a software company that can actually deliver when we say we will.
Want to know more about DLA? Read our blog about it!
Here’s the thing. Software developers know software. They don’t know business (usually—of course there are exceptions). In general, our developers are writing software that will make your business more efficient. They write other things, like Apple TV apps, etc., but mostly their work has to do with business. You want a BA involved in your software development process because they know business.
They say the devil is in the details. But really, the devil is in losing track of the details. And losing track is easy to do. Trust us. But at EduSource, we believe the essence of your business is in those defining details. Our BAs are tasked with collecting all of those details and keeping track of them. To build effective software, we need to know all about your workflow and how each piece of the process works in the whole. We need to know how you think, and how your employees think. We need to know about your revenue streams, about your decision-making, about how we can save you time, energy, and anxiety while we make your business model as smooth as possible.
The best software integrates seamlessly into your business. Having both a Business Analyst and a Software Developer involved in your project is how we make sure that seamless integration happens.
Meet our Business Analyst, Erik Fritzsche.
Let’s clear up the acronym first. UAT stands for “User Acceptance Testing.” It’s the process you go through to make sure the custom software you’ve commissioned is what you need.
“But I have no idea how software works—shouldn’t someone more qualified test it?”
Actually, you are the most qualified person to perform UAT. Remember, the “U” stands for “user.” The goal of UAT is not to establish whether the inner workings of the code are good (that’s another issue for another group of people).
Instead, the goal of UAT is for you to sit down and make sure that the custom software you’ve commissioned works for you and your business. And you’re the best one to do it, because you’re the one who will be using it.
“What if it doesn’t work? Can I return custom software?”
The name UAT can be misleading. “Acceptance” implies that you could also reject the software if you decide you don’t want it anymore. Personally, I think User Confirmation Testing would be a better term, since you’re confirming that what you’ve received is what you agreed on.
Let’s say you’re having your final wedding dress fitting (I know, bear with me). You’ve already decided what you want and the dress is almost complete. You try it on and notice that it’s a little loose and the hem is a little long.
You can’t return a custom wedding dress, and you don’t want to, since it’s almost perfect. Some tweaks need to be made, but the overall results are there as you expected. So you confirm the dress, have the alterations made, and get on with the wedding planning.
That’s UAT. You’re confirming that your expectations have been met and identifying any tweaks that need to be made before using the software for real.
It’s unlikely that the software would need to be overhauled or large changes made in this phase since the software was already made to your original specifications.
That’s the basic idea, but there’s more to the story! Read more here: What is User Acceptance Testing (UAT)?
We hire college computer science majors after their sophomore year for our apprenticeship program. Apprentices work full time during the summer and 15-20 hours per week from campus during the school year. We hire students for two full years (which is a stark contrast to an internship, which consists of spending a few months with a company during the summer).
Most computer science internships involve a lot of software testing and not much of anything else. But at EduSource, we want you to experience real-life software development.
One of our EduSource mantras is “developing people” (not just code). By the time our apprentices graduate, we want them to know more than just good coding practices. We want them to have grown as people.
To learn more about our apprenticeship program or to apply, visit our apprenticeship webpage.
Just because the young people in our office wear cargo shorts and flip-flops and can occasionally be seen watching “The Office” with headphones over their lunch hour, don’t assume that they should be treated like “interns.” We do, actually, have a lot of interns (read more about our two-year apprentice program here) around. But it would be a huge mistake to think that these students are best used by getting coffee or making copies. We choose our apprentices carefully, and boy, are these students impressive. They start writing code by their third day with the company and are some of our most bought-in employees.
We are always on the lookout for “experts” in different areas of technology within the company, and several of these unofficial titles are held by people that have been out of school for 1-2 years. Makes no difference to us. Why should it?
Back when Jason had a small company (called jrbeutler, inc.) that consisted of, well, just himself, he was consulting at a local logistics company and overseeing an outsourced team from India. At the same time, he was teaching a computer science class as an adjunct professor at Taylor University.
As the semester wore on, Jason discovered something surprising: the students were writing better, more concise, more maintainable code, than the India team. An idea formed: what if we outsourced software-writing to local college students rather than overseas?
From there, the ideas snowballed. What if we brought in a few carefully selected students to work as a part of our development team? What if we hired them for two full years and spent the time training them to program in a real development environment, as a part of a real programming team? Thus, the “EduSource” part of jrbeutler, inc. was launched.
That’s not the end! Check out this blog post to read the rest of our story.
At EduSource, we’re anything but mundane. So when we convened our leadership team and tasked them with creating core values, we got some craziness. “Let’s base each one on a movie character.” “Or how about an obscure TV personality?” We got a lot of ideas. We had a lot of debate.
At the end of several meetings, we agreed on one thing: we wanted each core value to have a story. We wanted them to mean nothing to someone who just walked in off the street and everything to our team. We hoped by using core values that told a story, our team would remember them, internalize them, live them. Here they are:
1. Crownless King
Protect each other
Protect the team
March as one
3. Figure-it-Out Gene
Make it better
Strange words, we know, but packed with meaning for our company. Want to learn the stories behind them? Read our Core Values Blog.