“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.
Since this is a newer term in the industry, here’s what it means to us:
We believe that clients should be motivated financially to manage scope and budget. And that we should be motivated financially to manage the efficiency of our software-writing process. Traditional models are backwards, with the software company acting as the scope manager or the client trying to keep engineers working in the most efficient way possible.
How do we turn those traditional models upside down? At EduSource, clients pay weekly for a team to complete User Stories on your project. Each week, the client gets a set number of EduPoints to “purchase” User Stories that the engineers work on.
The client is able to make informed decisions about changing scope, because they know that it may add to the project’s timeframe (and thus, affect the budget). And we are motivated to keep our teams operating as efficiently as possible, because we are committing to moving a certain amount of work through our process. If we get behind, our client doesn’t pay for catch-up time.
Both parties are motivated appropriately in this model. It’s a win-win. We call it Agile Contracting.
An EduPoint is a measurement we made up. It is similar to a Story Point, if you are familiar with that term. If you aren’t familiar with it, think of an EduPoint like a token. You get an allotted number of EduPoints, which you use to “purchase” (or start) User Stories for development. The number of EduPoints you get depends on which Project Mode you’re developing in.
In your Discovery Phase, our team will work with you to break your project into specific features. Think of it like this: I need a new car. I want the car to have air conditioning. That’s a feature. I want the car to have four-wheel drive. Again, another feature. In the software world, we call these features “User Stories.” Your software project will consist of a long list of User Stories.
Each week, you’ll meet with your Client Relationship Manager (CRM) to replenish your User Story queue. The meeting can be in-person or by phone, whatever fits best in your schedule. You’ll meet with your CRM to decide what new User Stories should be next in line for development. There will be some restrictions, like two larges is never a good idea. But your CRM will be able to help you with these choices.
The best answer to that is “usually.” Of course, it depends on what resources are available in the office. To give us the best chance to work this out, try to plan as far ahead as possible. If you know you’ll have a larger weekly budget available in a month, let us know as soon as you know, so we can plan.
Nope, that’s not how EduPoints work. Each User Story is made up of a set amount of EduPoints, depending on its complexity. Stories range in size from extra-small (which takes only about half a day to develop) to large (which takes more than a week). The breakdown is as follows: extra small (1 EduPoint); small (3 EduPoints); medium (5 EduPoints); and large (7 EduPoints).
Sometimes the math won’t work out perfectly. For instance, you might decide that next in line should be two smalls and a medium, but there’s no extra-small handy to round this out. Don’t worry – we’re looking for an average of points. Some weeks your Client Relationship Manager (CRM) will have you pick more than your allotted points and some weeks less. Your CRM will help you walk through this process to ensure that your queue will work for the development team.
We would love to tell you that this won’t ever happen. But that simply isn’t true. We have great faith in our estimating ability, but technology is complex and sometimes still surprises us. More than 95% of the time, your selected User Stories will be completed and ready for you to test within three weeks. Some of them will be finished as early as the next week. EduSource uses complicated metrics to ensure that we are on track. (Curious to know more? Ask us!)
Our commitment to you is that if we get too far behind, we’ll let you take a week off your payment schedule, and we’ll use the time to get caught up.
A bug is when your system doesn’t work according to the agreed-upon acceptance criteria. If the system isn’t functional, that’s a bug. If the system works as designed, but once you see it, you would like it to work differently, that’s not a bug. The great thing about Agile Contracting, though, is that it also isn’t a problem.
Whether you pay for the bug fix depends on when we find it. If we catch it during our internal testing or you find it during User Acceptance Testing (UAT), we will fix it as part of that story. If you’ve already signed off on the story and it is considered done, we will log a new User Story to fix the bug.
Either finding a bug later or changing your mind about how something looks or feels can extend your timeline slightly. These changes will be added as new User Stories, and you’ll add them to the queue when it makes sense.
Each week in your replenishment meeting, your Client Relationship Manager (CRM) will demo new functionality to you. At this point, you’ll have a week to play with the new User Stories, using them in every way you can think of, and report back to us. Any bugs you find will be fixed at this point. Tweaks you want made will be added as new User Stories.
No. We use Kanban methodology, which is more about getting stories finished than rigidly starting a certain amount of new ones at a certain time.
Each week, your team will pull some of the User Stories you’ve chosen into slots for development. From there, your team members will assign work and complete the software process for each story. When they complete stories and have availability, they’ll try to help finish current in-progress stories, then they’ll start work on a new story. Eventually, they’ll pull in more work as they need it. Sometimes they’ll get ahead of their EduPoint rate, so your Client Relationship Manager (CRM) will help you plan out some extra stories, just in case.
Because we use apprentices for some of our work. We hire computer-science university students during their junior and senior years to work for us. They start working for us in the summer, when they are on-site. During that face-to-face time, they go through extensive training to be ready to serve right on our development teams, along with our full-time software engineers. Once they are back at school, our teams are in contact with these students daily, assigning them work that they complete around their class schedules.
Since our apprentices work at a lower rate than even entry-level software engineers, we are able to provide you with a less-expensive option than many other companies.
Probably not. Even though it takes on average a day for our engineers to complete a small User Story, there’s a lot more to the process of getting it into a state where you’ll start User Acceptance Testing (UAT).
For one thing, every User Story written at EduSource goes through extensive code review to make sure it holds up to our stringent standards. It’s important that our engineers are following best practices, so that any subsequent software engineer could pick up our code and follow the logic. Any problems here will be flagged for the engineer to fix.
After code review is complete, stories go to internal testing, where we try to break the functionality. We occasionally catch a few bugs here, which will then be sent back to the engineer for fixing.
When all of these steps are complete, your User Story is ready to be moved into UAT. This could be as soon as three days later for a small or even seven days, depending on how many fixes are needed and how quickly testers and code reviewers are available.
All that’s to say that you might have a few small User Stories ready to play with in UAT the first week, but you’ll start seeing a lot of functionality after the second and third week of development.
That’s the million-dollar question of software development. If we could only invent a way to read our clients’ minds and pair that with magic understanding of any curve balls the technology is going to throw at us, we’d be set for the foreseeable future.
Unfortunately, no one can answer that without really diving in. In fact, if a software company gives you a hard estimate without going through a fairly elaborate estimation phase, our advice is to run. The company is either making really big assumptions about your project or is trying too hard to get your business. It’s not going to end well.
That’s why we believe in the necessity of a Discovery Phase. We don’t feel good about asking you to commit the budget necessary to complete a project without really knowing what your company needs. We always start there.
So how do you know if you have even the ballpark of budget necessary for a project? Fill out this form to request a consultation—it’s always free at EduSource. After digging in and getting a general idea of your software needs, we can place your project in a bucket, which will give you a ballpark idea of what size we expect the project to be. That should help you decide if your budget is large enough to make the Discovery Phase worth the cost.
At EduSource, we use Agile methodology. Agile is an umbrella term for several more specific software development methodologies. Books have been written about the topic but here’s a really basic definition: Agile seeks to incorporate continuous improvement in the software process, compared to a traditional waterfall method which is known for a sequential design process. In waterfall, there’s no room for change, so a project outcome and extensive plan must be set in the beginning, then followed carefully.
Within Agile, there are two main types of methods: Scrum and Kanban. EduSource uses Kanban, which has an emphasis on continual delivery and a system where work is pulled through the process and changes can be made at any time. Ever heard of Lean Manufacturing, which was first made famous by Toyota? That Just-In-Time method provided the basis for Kanban.
Internally, we also use a system called Daily Layered Accountability (DLA) to make sure our teams are on track for meeting deadlines. Each morning, teams meet to assess certain metrics, including Delivery, Efficiency, and Cost. We are really proud of this system, as it’s solved a problem that custom software companies have been dealing with for decades: completing projects on time. Our DLA metrics are predictive, so they let our teams know that something is in danger of being late before it even is.
So what does EduSource use, as far as software methodology? We use Agile Kanban, with Daily Layered Accountability. Agile and Kanban are known in the industry, but Daily Layered Accountability is something specific to us.
If you’re asking this question, you aren’t very familiar with EduSource.
No worries. We’re happy to explain. We almost never use contractors, nor do we ever outsource our software projects. You see, EduSource really came out of the frustration of working with an outsourced team. From that experience came the idea for our apprenticeship model. We now have anywhere from 8 to 12 apprentices working with us at any time. They work right in our offices during the summer but work remotely from their colleges during the school year. That’s the only kind of “outsourcing” we ever do, but it’s far from true outsourcing. Instead of working as contractors, the students are employed by EduSource and work right on teams with our full-time developers.
Yes! One thing we’ve learned from years of running custom software projects? Communication has to be a top priority.
When development is running super smoothly, it’s easy for software companies to keep heads down programming and go radio silent on the client. In the meantime, the client is thinking, “Did they stop working on my project? Are they just taking my money, but not actually doing anything? Is it going to end up costing WAY more than expected, and they are afraid to tell me? Did they break everything?”
That’s why we now have one person completely devoted to client communication. Not only do we guarantee that we’ll send you a weekly update about how we’re doing, but if you are on one of our project modes, we’ll have a weekly replenishment meeting and demo. But in the meantime, what if you start feeling stressed and have questions? Just pick up the phone or send off an email to your Client Relationship Manager (CRM). It’ll be a real person you’ve met and know.
And that’s the benefit of a small company.
Another note here: while we absolutely want you to meet your development team and even stop by to visit, we don’t encourage you to contact them directly about your software. This is for two reasons. First, we want our developers focused on creating great software for you. Believe it or not, client communication can take up a lot of time. Second, it can just plain get confusing when the CRM thinks the client wants one thing, but then the client contacts the developer and suggests a new idea. Pretty soon we aren’t sure who has the latest news and things get really dicey. But our CRM is always available to make sure you’re happy with what you’re getting.
Definitely! We hope you’ll come meet your team, and they’ll occasionally be on hand during demos.
But also, if you get a hankering to come visit us on a random Tuesday at 10 a.m.? You are absolutely welcome. Just so you know, things can be pretty dull around here on Tuesdays at 10. But if you bring donuts, you’ll be instantly popular.
We do. In fact, we recommend it when we’re finishing up your project. For complex software systems, there will always be needed updates and tweaks. By signing up for a Maintenance Mode contract, you ensure that our team has hours for you built right into our weekly schedule. (And you can budget accordingly.)
The silver lining? You still get to be part of the EduSource family, even after your project is finished!
That’s our goal. After all, you’ll need to know which developers get the big hug when you’re wowed by your completed custom software.
Occasionally, priorities will get shifted in the office, though, and we’ll need to move people around. There is some spin-up time involved whenever this happens, but don’t worry. This is absolutely on us. We’ll make sure your EduPoints still get completed in the allotted time.
You know our apprenticeship program? Well that absolutely came out of our desire to mentor young developers and help train them in real-world software and leadership principles. But you know what an amazing, unintended result is?
Ready-made employees. We are thrilled when the stars align and we’re able to hire a graduating senior. Of course, we’ve already spent two years training and investing in them. And they’ve spent two years deciding if they are passionate about what we’re doing here at EduSource. It’s a win-win.
This means our company is home to some pretty young engineers. But we also have the necessary 20-year vets to help lead the charge. And the youth never bothers us, because we believe in the abilities and innovation of these younger programmers. Let us tell you—our 24-year-old engineers? They’re smart. Man, they knock our socks off. You definitely want these young adults working on your projects.
As far as qualifications go, every software engineer at EduSource has graduated from a 4-year college or university, with a degree in Computer Science or something related. In fact, we believe in formal education so much that every single full-time EduSource employee has, at minimum, an undergraduate degree.
Your main team will be a mix of full-time engineers and apprentice engineers. But other people will be pulled in and out as needed. These people will touch your project occasionally:
Once our developers have finished work on a User Story, and it has gone through Code Review, and it has been tested internally (and any needed fixes from any of those stages have been completed), we will transfer the User Story into your User Acceptance Testing (UAT) environment.
When you meet with your Client Relationship Manager (CRM) weekly, she will demo any new User Stories for you, and show you how to complete UAT on them.
During that week, as you have time, you’ll be testing the heck out of the new User Stories. Anything you find will be separated into two categories: bugs and new functionality. When you click on a “Add a New User” button, and nothing happens, that’s a bug. If you decide that you’d like to move the button from the top of the page to the bottom, that’s new functionality.
Bugs will be sent back for re-work under the original User Story. New functionality will be defined by a Business Analyst (BA) and separated into new User Stories (for something like this example, an extra small or 1 EduPoint).
When you sign off on the User Stories at the end of your week of UAT, we consider that work “done.” It’s an important designation, because our goal is always to keep moving forward with your software, and not continue to change things over and over again. That’s also why we need you to set aside time in your week to go through UAT. We don’t want User Stories to be clogging up our system, never getting finished. That’s why we ask that you always complete UAT within a week of getting access to the User Stories.
So does that mean that once something’s done you can’t touch it again? We’ll be encouraging you that way, since we want to keep moving forward. But if you find something that doesn’t work, or you get a much better idea about how to change something, we can always go back and rework. But keep in mind that it will affect your timelines, and thus, your budget.
Soon, but not right away. Remember, User Stories can take up to three weeks to get all the way through our system. There will be things that need to be finished, including testing, code reviews, and fixes that come out of those things. In addition, getting everything set up in the production environment takes some time for our team.
As you near the end of your EduPoints, talk to your Client Relationship Manager (CRM) about how many more weeks your project will take to complete.