Def Method



  • I have an idea for a product. Should it be a mobile app or desktop app?

Unless you are leveraging something that can or should only be done on a phone (like hailing a ride from Uber or Lyft), you should opt to build a web application first. Your product and idea are new and need room to grow. You're far more likely to gain traction by asking a new user to click a link to your website than by asking them to take out their phone, search for your app, download, install, and run it. Down the road you can always build out to phone apps by leveraging what you've already built for the web.

  • What is the relationship between a desktop app and a mobile app? Can one be leveraged to create the other?

Mobile app typically refers to an app that you download from your phone’s OS’s (e.g. Android, iOS) app store. A desktop app is an app that you download to your computer. Sometimes these still come from an app store, but often they are downloaded from a website. A web app runs in your browser (e.g. Chrome, Safari, or Firefox).

Recently, the lines between these different app types has become blurred. The prevalence of “always on” internet connections means that mobile and desktop apps are generally connected to the internet. Additionally, the ability to save bookmarks to web applications on your desktop or home screen can make them function more like a desktop or mobile app, respectively.

The technology to build the user interface for each of these types of apps is different, but they can all share the same server in the background. For example, with an app like Evernote, whether you are interacting with your notes on your phone, in the browser (at, or on your desktop computer, the notes may all be uploaded to the same server. The server is what allows your data to sync between all of your devices.

Mobile and desktop development has been coalescing, as OS developers try to provide a more consistent experience across platforms. With laptops, tablets, and phones approaching a similar intermediate form factor, the lines are more blurred than ever.

  • What's the difference between frontend and backend development?

 Backend development refers to development of code that executes on a server. Frontend (client-side) development is for code that runs in the browser (html, css, javascript). Frontend code can be viewed by the end user because it is running on their computer, whereas server code is inaccessible.

The most common method for interacting with backend code is via the HTTP protocol (those first four letters in your URL bar). Whenever you visit a website, you are first making a request to the server to receive the code that will be rendered or executed by your web browser.  

  • What is pairing? What are the benifits?

Pairing is where two developers of any range (generally a senior and a junior pair is seen) work on a problem together. Like any good developer, they should plan out how the problem should be solved and think through possible edge cases they may encounter. When pairing, the pair usually shares a screen.  There is a 'driver', the developer who is typing into the editor, and a 'navigator', the developer who is narrating what should be typed based on their planning and thoughts.
The nice thing about pairing is that you get two really smart people working to solve a problem together. If they plan and pair properly, even though it may take some extra time, by the time it reaches QA you will have an excellent piece of code that was well-thought out, circumvents dastardly edge cases, and showcases the best of both developers.

  • How many developers should I use for my project?

Depending on the complexity and time-sensitivity of your project this may vary.  For teams bigger than one, pairing teams are typically best. 

  • When is refactoring needed?

Refactoring is a constant conversation between the team in order to balance the ease of extensibility of the application, and the need to complete features. In general they are driven by various code "smells." As with any smells, they may not be a sign of an actual problem, but they may be symptoms nonetheless. It is up to the team to identify particularly egregious code smells, and gauge whether or not they pose a true problem to extensibility, new engineer understanding, performance, or any of the myriad of other goals, both personal, and business facing that a developer wants to fulfill.

  • What can software engineers do to reduce scope?

Ideally, a software engineer would work with a product manager to scope a project. In agile software development, each iteration should be scoped to the set of stories that the team reasonably believes can be completed in that time frame, based on point estimations and established velocity. This scope of work should be flexible, incorporating slack time and taking into account that estimating complexity and the amount of time necessary to complete a feature is an inexact science.

During story development, an engineer must not be afraid to push back against scope creep. Aspects of a feature that were not included in the original story specification should probably go into a new story; otherwise, it will increase the variance in the team’s velocity and make estimating future iterations more difficult. This underscores the importance of the Iteration Planning Meeting (IPM) to ensure developers, designers, product managers, and other stakeholders are on the same page before the work begins.

As a launch deadline approaches, the team may be forced to forgo certain non-critical features, and should work together to ensure the remaining available development effort is focused on the highest-priority features.

  • What does "continuous delivery" mean?

Continuous delivery occurs when two components of software development - integration and deployment - are automated. Whenever new code is written it must be merged into the existing code base. This is software integration. In order to make sure the integration is successful, automated tests are run against the newly integrated code. At Def Method, we write thousands of automated tests during the lifetime of a project. These are all run every time new code is added to the code base. If all of the tests run, it’s time for deployment. If any of them fail, it’s time for the engineers to look at what went wrong.

Assuming all tests pass, it’s time for deployment. A continuous delivery system knows the steps to get the newly integrated code onto a server where the application as a whole can be viewed by our customers. Continuous delivery, when done correctly, saves hours of engineering time and gives our customers on opportunity to observe the application being built in real time.

  • How do you avoid repetitive code in your code base?

We follow the "DRY" guideline, which is short for "Don't Repeat Yourself." Repetitive code can be removed by using object-oriented or functional solutions rather than procedural code. But duplicate code can always creep in, which is why we test-drive all of our code and look for ways to optimize it whenever possible.

  • Why do you recommend Heroku?

Heroku was the first company to offer Platform as a Service (PAAS), a way of hosting web applications that obviates the need for software engineers to set up and maintain deployment and monitoring solutions.

Well beyond mere “hosting in the cloud,” Heroku automatically manages many tedious, complex, and time-consuming tasks in an automated, transparent fashion. Heroku automates custom and/or manual deployment, log rotation, process monitoring, and many other infrastructural necessities so our engineers can put more focus on building and delivering software.

Heroku supports Def Method’s adherence to the Twelve-Factor App principles for software deployment and maintenance. It also allows for quick and seamless scaling of our architecture. In other words, Heroku is built on solid infrastructural principles, and its architecture is able to grow and scale alongside your business.

  • What language do you use?

The Def Method Engineering Team is language agnostic. We source our engineering talent from a variety of different language expertise and experience so that we can nimbly recommend the best language for the job instead of the one we happen to know the best.

In practice, this means that we talk with our customers to assess their software requirements, existing infrastructure and architecture, and any technical decisions that have been made to date. We also assess 3rd party integrations, user experience considerations, and end-user workflows that may be complex or computationally intensive.

  • How can I ensure a smooth project release?

One could argue that shipping is the hardest part of software development. At some point, you have to stop making tweaks and enhancements and release the work to the world.

The most troublesome releases come from trying to do too much in too little time. A project needs to be managed carefully to avoid falling into this trap. Def Method recommends using an agile process to develop iteratively. In your kickoff meeting, set a target for the vital features for launch, then check your progress towards this Minimum Viable Product (MVP) in your weekly IPMs. Ensure every story contributes to this launch.

Following Test-Driven Development (TDD) will give your team confidence that the features built for launch are robust and ready to use. Setup infrastructure, like CI/CD, early to reduce the burden of deploying features and stay focused on development.

Take advantage of beta testers. You can use a subset of your current users, through an AB Testing Framework like Optimizely or an invite/opt-in system built into your app. You can also use a site like to get external users, who may be unfamiliar with your product, to test drive your app’s design. You should also have a battery of internal QA testers who are skilled at trying everything they can to make your app break (though they should largely be unsuccessful in their efforts).

As the final launch approaches, freeze development of new features. Have your team smoke test the app and focus any available development time on addressing bugs. Ideally, the number of defects will be very low, if you have followed the advice above. If possible, stress test your hardware to ensure your servers will be able to handle the influx of users.

Finally, press the launch button and make your hard work available to the world! Celebrate with your team on another successful launch! 

  • How long will it take to build my first MVP?

It depends on the features you would like included in your MVP.  Check out the project length calculator above to get a rough estimate. 

  • What are the benifits of unit testing?

Unit testing is the process of sifting through your code and thinking 'okay what will happen in the happy scenario (when everything is received and happens as it should)? Now, what should happen when things are trying to blow my code up?'.  As developers are coding they can't possibly think through all the scenarios their code could break under and how to find solutions in those scenarios. They can write tests and set down some initial logic for those tests to pass. Testing is extremely important and if a developer isn't doing it, I wouldn't want to hire them. 

  • What do I do if my site goes down?

If your site was built well you would have found out by an email from a monitoring service (such as Honeybadger) before too many of your customers are affected. Then after some quick testing/debugging, a fix can be found, implemented and deployed with confidence since the site's comprehensive test suite will ensure any code change for the fix will not affect other features. In fact the deploy of the fix would be automated by your continuous deployment process.

  • How can we make sure our application is scalable?

There are many ways of helping with scalability. The first is to simply identify what the desired scale will be. Will it be thousands, millions or 10s of millions of concurrent users? This helps to constrain design choices into what is feasible, and worth pursuing. After that, depending on the nature of the application, there are many ways of making your application future facing. Breaking the application into more of a micro service architecture, using a blockchain messaging system instead of a stateful transactional database, throwing more hardware power at it, these are all potential methods to scale your application properly. 

  • How do I maintain a healthy application when it is not being actively developed?

First, use thorough automated testing of the application to avoid regressions and provide complete specifications of the system to inform maintenance (test-driven development). Second, whenever fixing an issue, begin by writing a test that exercises the bug (test-driven development).  Particularly for an application with limited ongoing engineering effort, offload as much infrastructure as possible to platform-as-a-service (PaaS) tools like Heroku.  Finally, use current versions of all tools and systems, and update them periodically even if nothing else is being done on the application.

  • What is the "best practice" for usernames and passwords?

Currently the best practice for usernames is to

  1. choose a username that is substantially different from your email address and
  2. choose a username that does not reveal your full name.

These are not hard-and-fast rules but a good guideline. It's not necessary to go so far as using a complex username as you would use in a password because usernames are routinely exposed anyway. 

One way to manage passwords is by using 1Password,  LastPass,  Dashlane,  or similar password management tools. These will generate incredibly complex passwords for each site you visit and store them behind very tight security. The best part is that users don't even have to remember those passwords; the tools work with your browser and will load in username and password information when you visit a site. This is similar to Chrome autofill but more secure, as they employ extra security measures that prevent a would-be attacker from getting at a user's master password.

It's tough to rate one password service higher than the other because they are all very highly respected password security managers. One thing that matters is whether your users all use Macs, all use Windows, or there's a mix of the two.  If you're all on Windows or if there's a little of both, then use LastPass. It's entirely browser-based and compatible with every machine and device.  If you're all on Mac, I recommend Dashlane slightly above 1Password. Neither is great for Windows users (or Linux users).