What Engagement Managers Should Know About Development
Melissa Keeling • Nov 09, 2018
As an Engagement Manager, you know how to lead meetings, keep your project team on track, and communicate with everyone involved. In an application-development context, you can do your job much more effectively if you also understand the phases, components, and tools of a development project.
In this blog, I’ll share some high level concepts from an Engagement Manager’s perspective that will hopefully help you understand enough to keep up with a conversation so you can manage your project more efficiently.
At DeveloperTown, an Engagement Manager is a Project Management, Business Analyst, Quality Assurance hybrid role.
FRONT-END VERSUS BACK-END PROGRAMMING
Typically, a software application has two parts: a front end and a back end. In the simplest terms, the user of a program can see what the front-end code does, and the back-end code provides and manipulates what is shown.
For example, say a program displays a table of the names, hometown, and best times for runners in a race. The front end is the actual table, colors, fonts, and so on. The back end is the database that holds all the runners' information.
As an engagement manager, you need to make sure the front and back-end developers are aligned so they can produce an application that works and is appealing.
To create an application, a developer can choose from many languages, and every so often, new ones become popular. Programming languages are similar to languages we speak in that they each perform the same purpose but have a different structure or advantage.
https://securityboulevard.com/... an engagement manager, you need to understand what languages your client's existing systems use, make sure your development team has the information they need to choose the appropriate languages for the new product or update what they're currently delivering and why. With this information, you're able to provide or suggest what is best for the client.
Developers write an application's base code on top of a platform, such as Android, iOS, or the Web. Because each platform is constructed differently, some languages, such Swift for iOS, are platform-specific.
Traditionally, apps for the Android and iOS platforms (known as native apps) were developed separately. Now, however, developers have multiple ways to write one application that works on both platforms (a hybrid app).
FRAMEWORKS AND LIBRARIES
Frameworks and libraries are tools developers use to write application code. A framework provides a standard way to build and deploy applications. With a framework, programmers can easily follow a pattern or build into a structure that keeps code simpler and similar to other projects. An example would be Rails.
Refactoring is a process that makes code as efficient as possible. Refactoring should should be done consistently, but can be put on the back burner. After a feature is working the developer refactors the code if time permits. Refactoring helps lower technical debt (code that will eventually need to be redone for the program to continually work well) and makes the code cleaner and easier for another developer to read or add to.
https://codeandwork.github.io/... can see from this image that in the beginning A connects to B, but the connection is more complex than necessary. As code is continuously refactored, the connection gets easier to see resulting in cleaner code.
Testing should be considered when initially defining a feature. If a feature isn’t tested well enough to ensure it consistently works or brings the right value, what’s the point? There are multiple ways testing should be implemented to truly know the software is robust and working properly.
With Test Driven Development (TDD), the tests are written first, and then the code is written to pass the tests. This allows the feature to pass both technical and business test cases.
Unit testing checks specific chunks of code. These are usually automated to run constantly.
Regression testing, another type, is similar because it tests older code to make sure newly added code doesn’t break anything that was previously working.
User testing of the application is performed to test aspects that aren’t technical or hard to catch. For example, is the user logged in after clicking three specific buttons in a common sequence?
The name and number of development environments depend on the project need. At a minimum, there’s typically an environment for developing, internal testing, and end users (production).
The developing environment, also known as a sandbox, is where developers write and test code. Changes or new features are created in the developing environment first, so it probably looks different than the current software version available on an app store or public web page.
Then the changes are pushed to what we at DeveloperTown call a “staging” environment. In staging, features can be tested further and the software looks the way it should.
Finally after the product owner approves the feature, it’s pushed to production and becomes live.
This graphic represents an example of how environments can be set up and shows the transition from one to the next.
CI / CD (CONTINUOUS INTEGRATION AND CONTINUOUS DEPLOYMENT)
Continuous Integration is the practice of merging code changes into a shared repository several times a day in order to release a product version at any moment. Continuous deployment aims to reduce the time that elapses between writing a line of code and making that code available to users in production.
Continuous Integration and Continuous Deployment are used to keep developers in sync and testing/using new features quickly. This requires an integration procedure that is reproducible and automated.
DevOps is a software practice that brings together software development (Dev) and software operation (Ops) in a way that helps teams deploy software more quickly. Development includes the codebase and testing. Operation includes deployment and monitoring. DevOps simplifies the transition from creating the software to pushing it out where it can be used.
Keep in mind this is base knowledge of the concepts, intended to help you get more familiar with common terms you’re likely to hear or experience when first entering the software development world. If you find yourself confused or want more information, I’d recommend reaching out to a developer you work with to see how these concepts play out in your company.