Droidcon Lisbon 2019: An Overview

Droidcon Lisbon 2019: An Overview

Droidcon Lisbon 2019: An Overview

This week, I attended a Droidcon event in Lisbon, Portugal. The conference itself was at the University of Lisbon, known at this time of year for bright sunshine, mild temperatures, and a unique initiation ritual for freshmen known as Praxe, which was going on all around us. Aside from realizations of how comparatively good I had it in college, the conference was a fantastic experience, both for setting and content, and for the wide array of nationalities found amongst the attendees. 

It was interesting to share ideas and gain perspective from coders who, mostly, were not American. The conference itself was eye opening, and not just because I made what I assume is the very common mistake of drinking coffee-sized portions of espresso (“These cups are so small, that’s cute! Wait, why am I vibrating?”).

Here are three takeaways from Droidcon Lisbon 2019:

Size Matters

There were at least 4 presentations that directly related to the size of APKs. More and more people are relying on smaller APKs, and with the app bundle they now have the power to receive molecularly small file sizes. As with anything, we can take this to the extreme, such as only downloading features as we need them, saving the user a good 10 MB if they don’t want a specific camera feature, for example. 

I’m not entirely convinced that users examine file size when downloading apps, and I would think this is a lot of developers effort for 10 MBs. At a certain point, it feels a little like code golf but with APK sizes. I’m sure the benefits become far more clear on large apps with many features though.

Sometimes the theory is better than practice:

I’m a math and physics nerd, so whenever there’s an opportunity to learn exactly how satellites use trilateration for my position on the globe or how hackers gain access to encrypted passwords, I perk up a lot more than I would at a slide full of code samples. 

Talks by Richard Süselbeck and Xiaoyi Li on global positioning and password security, respectively, were just such talks. They provided info general enough for almost any developer conference. This is useful because it allows developers to expand their world beyond Android studio and competently discuss exactly why they should take certain measures regarding password security or location services.

Not that I didn’t enjoy slides of code samples. One of my favorite talks was ostensibly a showing of the ADB documentation, but I found the breadth and depth of its uses fascinating, and the examples that Zhenlei Ji provided were as useful as they were funny. (Have a bug that involves scrolling a list for five minutes? Don’t do it yourself, write a shell script using ADB commands to do it for you and go get a coffee in the meantime.)

DAE Coroutine? 

The biggest, most unavoidable topic of the conference was Rx vs Coroutines. Coroutines are obviously SO hot (you know..Mugatu…see right) and several talks explored their advantages/disadvantages vs Rx. My take is as mild as the breeze coming off of the ocean in downtown Lisbon: coroutines are easier to read and better to use for more common asynchronous tasks in Android. Almost anyone at Droidcon will tell you that. Because of this, more and more people will start using them. 

The downsides of Rx are not so great as it requires switching immediately, and there’s a hefty learning curve. A few speakers acknowledged, reasonably, that it will probably be better for your business to keep using Rx if it’s already in your project.

Before hearing about Droidcon Lisbon, I would have assumed that any international event would break the bank, but this inaugural conference was affordable, possibly because of its cozy two-track size. It allowed the event to be accessible on a financial level, besides Droidcon’s stated values of inclusivity to those from all walks of life and levels of Android experience. I would encourage anyone to look at the schedule for the next few months and see if they’d like to learn more about Android in Vienna, Shanghai, or Tel Aviv, for example. Maybe I’ll see you there.

John Surface

John Surface

Mobile Application Developer

With a birth weight of just under seven and a half pounds, John has in less than three decades managed to gain thirteen stone and several years of experience as a full-stack and mobile engineer. He does his part to slow the spin of the earth spiraling out of control by creating robust backend solutions and intuitive cross-platform and native mobile applications.

Healthy Astronauts & Cheap Apps: Benefits of Containerizing

Healthy Astronauts & Cheap Apps: Benefits of Containerizing

Healthy Astronauts & Cheap Apps: Benefits of Containerizing

Every one of us is designed and configured for life on Earth. So much so that if we were put in a different environment, we would die within minutes. Let’s take Mars, for example, if we didn’t implode due to the low atmospheric pressure, we would freeze to death. If we didn’t freeze to death, we would suffocate due to lack of oxygen. And if somehow we were still alive… we would die from surface chemicals, UV radiation, or lack of food and water.

The body is a system, and like most systems, it is very tightly coupled to the environment that it runs in. This tight coupling becomes a problem when we want to move environments. However, if we can decouple a system from a given environment, we can move the system without worry. This is called containerization.

That sounds cool. What Does it Have to do With Apps?

While there are many benefits to containerization, the most powerful is portability. A system is very useful when it works in multiple environments. This is true for not just lifeforms but also developing applications.

When NASA wanted humans to ‘work’ in space they containerized them. We can containerize a human by sticking them in a spacesuit. The more of the human you get inside the space suit, the more reliable their survival will be when you put them in space, or on Mars, or in AWS data center.

A space suit supplies and restricts elements so that it contains just what a human requires for life. It has Oxygen, it’s pressurized, it blocks UV radiation, and provides climate control.

In much the same way, we can containerize an application (An application can be virtually any program from API servers to databases to jobs) to require just what it needs to run in any environment that supports our containerization software. Doing so creates several benefits:

Why does Containerization Matter to Me?

  • Ease of Deployment and Configuration

    The most important benefit of containers is simplifying and speeding up the process of deployment and configuration.

  • High Scalability

    Containerization allow you to scale only the desired functions without impacting on the entire application

  • Increased Overall Productivity

    Containers allow developers to achieve next-generation efficiency in software delivery or allow product managers to save time and resources by settling many of the challenges that they face with traditional virtualization.

Fixing a bug takes 30 times longer than writing a line of code

This means that if something breaks when you are moving your code from one environment to another, you will not only lose productive time but also spend that much more money fixing it. More importantly, there is no upper limit to how long a bug will take to fix leaving your project at massive risk.

Containerization allows us to run applications under the exact same conditions whether we are developing on a local machine, testing on a quality assurance machine, or running in production. The result is faster development times, higher quality code, simplified deployment, and less dead astronauts.

Ryan Eghrari

Ryan Eghrari

Ryan Eghrari operates as technology consultant and software practitioner. He studied Computer Science and Mathematics at University of Richmond and University of Paris respectively.

The Importance Of Choosing the Right Architecture Pattern

The Importance Of Choosing the Right Architecture Pattern

The Importance Of Choosing the Right Architecture Pattern

What are software architecture patterns?


When writing software, engineers encounter many of the same problems over and over again. Because of this, design patterns have been defined that give engineers a reusable way to solve these commonly occurring problems. At a higher level, software architecture patterns exist that give engineers a way to accomplish the same thing structurally for the entire project. There are many different types of applications and each application might benefit from a different architecture pattern.

One of the most common patterns and one we use frequently here at Shockoe is the layered pattern. The idea behind the layered pattern is that the code should be split into layers and each layer should have a distinct responsibility, while also being able to provide some service to a higher layer. So, for example, you might have a presentation layer that responds to user interaction with a screen and then passes data to a higher layer (frequently an application layer) and so on and so on until it reaches the highest level that has been defined in the architecture.


Why does it matter?


One question that could be asked is – Why is it important to choose the correct app architecture? This can be answered from two perspectives; that of the engineer and that of the client. We’ll start by answering it from the perspective of the engineer.

Most engineers are familiar with common architecture patterns. This means that when a new engineer joins a project or a team of engineers takes on an existing project, they are better able to navigate the project structure and can begin work much more quickly and with more confidence that new features can be added without any issues. Additionally, as new features are added it is very clear which part of the architecture needs to be modified and teams can work together on different layers of the architecture. All of this leads to more stable applications with fewer bugs and better performance overall.

From the perspective of a client, there are many reasons why choosing the right application architecture is important. Clients need to be able to be sure that the engineering team that they choose to build their application has their best interests in mind, both in terms of quality and efficiency. Software architecture patterns allow for higher levels of quality to be achieved while still maintaining efficiency. There is also no one-size-fits-all architecture that can be applied to every project. For example, a highly complex enterprise level application would demand a more sophisticated architecture pattern than a simple proof of concept or minimum viable product application. Also, when a project is released and then additional features are required the client can be sure that this process will be as painless as possible because well-architected software can be modified much easier than software with poor architecture.




Building software requires planning. Without a plan, even a trivial project can quickly turn into an unmanageable mess. This introduces what is referred to as technical debt into the project. As technical debt increases, costs to the client increase and overall performance and quality of the application decreases. As I mentioned before there is no one-size-fits-all approach to software architecture and at Shockoe, we pride ourselves on being experts when it comes to choosing the right application architecture for each project and making sure that we deliver the highest quality applications to our clients in the most efficient way possible.


Stephen Shaw

Stephen Shaw

Software Developer

Stephen Shaw is a mobile software engineer, primarily focused on building native iOS applications. Born and raised in Richmond, VA, he enjoys spending time hiking by the river, trying new restaurants, and exploring everything the city has to offer with his fiancé, Rachael. Passionate about learning something new as much as possible, he is always seeking out ways to acquire knowledge.

Identifying Solutions with The Opportunity Tree

Identifying Solutions with The Opportunity Tree

Identifying Solutions with The Opportunity Tree

At Shockoe, we often have prospective clients come to us with a defined idea of what features they want in their mobile app. But more often than not, as we get deeper into the Discovery phase, we uncover truths that make us question if those features are actually the right solution for the problem our client is trying to solve. By then, it may be too difficult for our client to pivot to a new solution, as it would require all new buy-in from their stakeholders. When clients lose sight of why a decision is made, and are far more concerned about the tactical aspect or flashiness of a feature — It’s important to keep the user’s need front and center throughout the process and keep an eye on the overall outcome or objective.

Recently a group of us from Shockoe attended the rvatech/Women conference, and participated in a variety of panels and break-out sessions, such as exploring diversity in the workplace, creating a culture of innovation, and inclusive design. One of the more hands-on workshops was presented by Jenn Atkins, Katie Moriarty, Amy O’Callaghan and Rob Huddleston of Snag, that led participants through the exercise of creating an Opportunity Tree.

The exercise began in a way that seemed very familiar…. our “stakeholder” asked our table (the product delivery team) a simple request– “I need a boat. I need it in 3 months, and I have one million dollars.” We then got to drawing a mock-up of that boat, without asking the stakeholder any questions. At my table, the drawings varied from a mega-yacht, a souped-up fishing vessel, and a solid gold boat paperweight. Snag UX Researcher Katie Moriarty then asked us, “how many of you clearly understood what the stakeholder needed?” And of course, none of us did. So how did we expect that any of our boats would be remotely close to solving the stakeholder’s problem?

1. Outcome

In the world of mobile app development, clients will call us with the same kind of request– although instead of a boat, they ask for features– “I need an app with touch ID.” But instead of turning around and putting that feature in a scope of work, we should ask “why.” Here Snag urges us to follow Toyota’s 5 Whys method developed as part of lean manufacturing:

Q: Why do you need an app that has touch ID?
A: Well, when I use my banking app, I really like that I can just log in with my fingerprint.

Q: Why do you like logging in with your fingerprint?
A: I always forget my password for all these apps, so when I can log in with my fingerprint it just saves me time.

Q: Why does it save you time?
A: I always want to have really secure passwords, so I keep making up different ones for each account that have different combinations of letters, characters, numbers, upper-case, lower-case, and the names of each one of my pets and children. I also never write the passwords down, so how am I supposed to find them quickly??!

Q: And why do you need to log in so quickly?
A: Because if I can’t log in, I always just give up and close the app. I don’t have the patience to go through a long process to reset my password. And I don’t want our users to give up without being able to use the app.

You get the basic idea. By interviewing the stakeholder or client and listening to their responses, you start to get a sense for the desired outcome. So in this case, the desired outcome is not “an app that does has touchID.” It instead is “To decrease user drop-off during log-in by giving users an easy and fast way to log in.”

The desired outcome now goes at the top of The Opportunity Tree.

2. Problems into Opportunities

The next step of the exercise is to start identifying problems so that you can invert them to create opportunities. In the workshop, we did this by interviewing our stakeholder, but this could also be achieved in user research as well. The interview questions were framed around the outcome, and the stakeholder’s feelings around it. “When you think about achieving “X”, what worries you the most? What problems do you see personally?” The group furiously detailed each problem on a sticky note, and then organized them at the end of the interview. Certain themes emerged quickly, and we were able to craft three problem statements that covered all of our stakeholder’s concerns.

Now using our app example, problems might include:

  • I can’t remember my password.
  • I hate when my spouse can’t log in under our account because he doesn’t know the password.
  • I want to be able to get into the app right when I need it — I don’t have time to go through a whole log-in process.

Problem statements are now inverted to become opportunities. Each opportunity is in the voice of the consumer. So the problems above might turn into:

3. Solutions

Finally, we arrive at the solutions, or in our case, features. We now can brainstorm individual solutions that can ladder up to each opportunity. In our exercise, we quickly narrowed down to 2-3 solutions per opportunity. This gives our stakeholders a way to look at potential solves and weigh the value to the consumer, against the cost of the effort, and decide what’s worth moving forward with. In our app example, by doing this exercise our client may decide that no secure information is in the app, so a full authentication process isn’t necessary. And for their consumers, it’s more important for them to get in and use the app quickly than to be logged in.

At the end of the workshop, when we looked back at our outlined solutions, Katie asked us again, “how many of you clearly understood what the stakeholder needed?” And this time, all of us raised our hands. We were confident that the solutions we landed on would meet our stakeholder’s needs, and achieve the desired outcome.

By using an exercise like The Opportunity Tree in the initial sales process, clients and mobile app developers can be sure that the solutions they will be developing and validating all lead back to the overall desired outcome, even before a Scope of Work is signed. This simple process allows us to get to the root of the problems we’re trying to solve when sometimes our clients have trouble identifying what those are. So that by the time the product is ready to be deployed, we can all be confident that we released the right set of features to deliver the most utility to consumers, and business value to our clients.

Rebecca Thompson

Rebecca Thompson

Project Manager

Rebecca has over 10 years of production and project management experience in advertising and tech. She has led numerous national multi-media campaigns including television, print, out-of-home, radio, digital, social, and PR events. Rebecca approaches project management with three goals in mind: to keep the process efficient, team members happy, and the work cutting-edge and award-winning.

Scaling a Push Notification Server

Scaling a Push Notification Server

Scaling a Push Notification Server

Previously we explored the topic of setting up a sandbox push notification server in Node.js. This featured a Mongodb instance to store users and device IDs, as well as endpoints to register users and send them the push notifications all at once. But what happens when you need to target individual devices instead of blasting your entire user base all at once? All of a sudden instead of processing one API call to send notifications to all of your users, you’re fielding multiple calls at once, possibly on the order of thousands of requests per second during peak user hours for your application. Fortunately, Node.js has built-in tools to help you scale your server.

The first issue we can tackle is breaking our Send endpoint out to work as a tool to send an individual push notification. We’ll assume in this case that the requests to this endpoint will come from another source with knowledge of the device Id and operating system to target. We’ll again use restify to set up our server:



const restify = require('restify');

const server = restify.createServer({
name : 'pushTest'

// this allows us to parse the POST request body

server.listen(8080, () => {
console.log('listening on port 8080');

// set up a basic route
server.post('/', (req, res) => {
// parse the request body
let body = JSON.parse(req.body);

// check to make sure the body has the correct fields
if (body && body.platform) {
// send push here
// send a success response

We’ll skip over actually sending the push since we covered that in our previous post. Once we start the server, we can use the ApacheBench command line tool to load test it. In a separate terminal window, paste:

ab -p test.json -c 20 -t 10 http://localhost:8080/

Where test.json is a local json file with test data. This will open up 20 connections per second for 10 seconds on our server. When we run this we get an output of about 150 successful requests per second, but let’s see if we can do better. The cluster module ships with node and allows us to spin up a server for every CPU we have on our machine. In a separate file we can have a “master” node that spins up servers for every CPU we have on our machine:

// master.js

const cluster = require('cluster');
const os = require('os');

// check if master
if (cluster.isMaster) {
// find out how many CPUs we have available
const cpuNum = os.cpus().length;

console.log(`Found ${cpuNum} CPUs`);

// fork the process for as many CPUs as we have
for (let i = 0; i < cpuNum; i++) {
} else {
// otherwise spin up server

Now instead of running

node server.js, run

node master.js

On my personal machine, this spins up eight different instances of the push server, and when I run our same ab command, I’m now seeing over 500 requests per second. This works by running master once and then running it again every time cluster.fork() is called for as many CPUs as we have. If master.js is entered as a result of calling fork, the isMaster call will fail and it will spin up the server.

This is a simple example of the built-in power of Node.js to increase the scalability of your application and expertly handle any kind of heavy load your test servers might need to endure.

John Surface

John Surface

Senior Developer

With a birth weight of just under seven and a half pounds, John has in less than three decades managed to gain thirteen stone and several years of experience as a full-stack and mobile engineer. He does his part to slow the spin of the earth spiraling out of control by creating robust backend solutions and intuitive cross-platform and native mobile applications.

Google Flutter goes Beta at #MWC18

Google Flutter goes Beta at #MWC18

Google Flutter goes Beta at #MWC18

What is Flutter? 


According to Google, Flutter is a mobile UI framework for creating high-quality native interfaces for iOS and Android. As a Google Partner and a company that has focused on building cross-platform mobile solutions for individuals and organizations, it is amazing to see a product like Flutter be released into Beta.


Better than other Cross-Platform Solutions


First of all, this initiative is backed by Google, which gives it a strong start. Also, the performance and platform integration are seamless and the structure allows us to build at high speed with great performance on both major platforms (iOS and Android.) Sure, there are some bugs and shortcomings, but that is always expected in a Beta version. We are on a trial run and, so far, our team loves it.



The team at Flutter highlights the benefits best on their Medium Post (Seth Ladd, Product Manager @ Google for Flutter):


  • High-velocity development with features like stateful Hot Reload, a new reactive framework, rich widget set, and integrated tooling.
  • Expressive and flexible designs with composable widget sets, rich animation libraries, and a layered, extensible architecture.
  • High-quality experiences across devices and platforms with our portable, GPU-accelerated renderer and high-performance, native ARM code runtime.


As a cross-platform mobile application development company, we are very excited about this solution because we can start using it immediately with our current apps. We don’t need to write our complete app in Flutter, we can simply add new Flutter-based screens to existing apps. Flutter is better than most of the cross-platform solutions we use today because it allows us, not only to build for two platforms but to make changes to the source code and see the UI updates in seconds, making the development process significantly faster.


If you are interested in learning more about Flutter, please reach out to schedule an informational meeting.




Mobile World Congress (#MWC18)


MWC is one of the biggest events on the mobile calendar. This year, more than in the past, the focus is going beyond our traditional understanding of Mobile Apps and pushing into the connected life or what MWC is calling “Intelligently Connected.”


Follow Shockoe to keep up to date on the key themes this year:


  • Artificial intelligence and machine learning (AI & ML)
  • Forthcoming 5G & LTE enablement
  • IoT smart city technology and edge computing devices
  • Big data and analytics
  • Technology in society and net neutrality
  • Consumer smartphone and tablet devices

SQL vs NoSQL, the ultimate database match

SQL vs NoSQL, the ultimate database match

SQL vs NoSQL, the ultimate database match

In the blue corner, SQL stands with an arched back and titanium walker. In the red corner, NoSQL maintains steady movement and a toddler’s impatience.

Created in the early 1970s, SQL was the unrivaled choice for applications both large and small that were in need of storing, managing, and retrieving data. Deciding to implement a SQL-driven database was a no-brainer for developers and system architects because it was unmatched by its alternatives not only in reliability but also in its reporting capabilities. In recent years, however, SQL, the once unrivaled query language, is being replaced slowly but surely by the new kid on the block: NoSQL.

Let’s take a moment to evaluate and discuss the differences and similarities of these database models with a few areas of focus. For the sake of this discussion, we will use MongoDB as the NoSQL example and MySQL for the SQL example, but the assertions for NoSQL are not limited or specific to Mongo but also apply to numerous other NoSQL campers like MapReduce, Bigtable, Cassandra, and others. Many of these NoSQL technologies have similar capabilities and advantages, as well as weaknesses. Similarly, on the SQL/RDBMS side, we will reference MySQL, but the same ideas carry over for other solutions like Oracle, SQL Server, and others.

The Back Story
We first need a bit of backstory. We’ll begin by asking ourselves what SQL vs. NoSQL really means. To answer this we have to understand what a database and a database system are. Now, bear with me here, without trying to bore you to death, we may agree that a database is a system for storing and managing data and a database system is a program for managing databases. Got that? So next, the data in a database has to be organized in some way. The way in which various database systems choose to organize their data is referred to as a database model, and this is where SQL and NoSQL come in. On the surface, think of SQL as the relational model and NoSQL as the non-relational model. Diving deeper, we find that the relational model uses set theory and predicate logic, in which the data looks like it is organized in tables and columns, while the NoSQL model stores data as key-value pairs without any strict relation to each other. End of backstory; you’ve uncovered the plot, so now let’s jump straight to the three-round fight scene.


Data scientists and architects assert that SQL is not out for the count, and I agree. Relational databases have a huge advantage compared to these wannabe newcomers primarily because they have excellent tooling, community, and support. The “why change what’s working?” question comes up pretty often when developers and system architects are faced with the decision of rolling out a data management tool. SQL offers two main advantages: first, it introduces the concept of accessing many records with one single command; and second, it eliminates the need to specify how to reach a record; e.g., with or without an index. Since most NoSQL databases lack the ability for joins in queries, the database schema generally needs to be designed differently and lends itself to some inefficiencies, giving SQL round one of this match by a small margin.

Popular NoSQL databases were pioneered by top Internet companies like Amazon, Google, LinkedIn, and Facebook to overcome the drawbacks of the relational model. The relational model is not always the best solution for all situations as it cannot meet the increasing growth of unstructured data.

NoSQL is better for unstructured data

You may have paused to ask yourself why some organizations have unstructured data. Well, social media posts and multimedia are only two examples of unstructured data, which should answer that question, but more importantly, since the world’s data is doubling every two years, companies now have a much greater need to not only store and accommodate unstructured data, but also to aggregate and use this data meaningfully. This is where the relational model takes a hit to the face giving round two to NoSQL.

Round three has three main focus; performance, planning, and price. Ideally, this is where the rubber meets the road in this decision. With NoSQL, instead of retrieving all the data

with one query, it is common to do several queries to get the desired data, but NoSQL queries are often faster than relational SQL queries so the cost of having to do additional queries may be acceptable. So if an excessive number of queries would be necessary and the company’s culture values performance, SQL or NoSQL may take the performance point for this round.

Planning is the second judge and it is very important, yet subjective. SQL databases have predefined schemas while NoSQL databases use a dynamic schema due to the nature of unstructured data. Therefore, SQL databases can be scaled vertically whereas NoSQL databases can be scaled horizontally. This means that to scale an SQL database, we simply increase the processing power of the hardware, while to scale a NoSQL database, we increase database servers in the pool of resources to reduce the load. Based on the organization’s planning culture, either SQL or NoSQL can take the planning point and this leave price as the final factor.

All companies make an effort to keep cost low so price an important factor. Most, if not all NoSQL databases are open source or very very low cost, which makes them very appealing. For the example, MongoDB, Couchbase, CloudDB, and Amazon’s Dynamo DB all allow very affordable implementations. On the other hand, among the major players in the SQL space, only MySQL (and its fork MariaDB) offers an open source solution. Both Oracle and SQL Server can be very expensive solutions due to the support they offer, which is usually readily available from their vendors or a fair number of independent consultants. NoSQL databases rely mainly on community support.

The Judge’s Decision
Depending on your vantage point or who you ask, some may agree that this match could have ended in a technical draw a few paragraphs prior, where unstructured data was a definite need and nothing else mattered. Another vantage point may have revealed that this match has ended in a TKO if no budget was allocated to database implementations and management couldn’t care less about database models, giving priority to an open-source-only solution. Ultimately, you decide who wins round three and therefore the match.

Despite your vantage point or decision, we all can agree that SQL and NoSQL serve very different purposes, with their own unique strengths and weaknesses; without them, developers and system architects would have been pulling their hair out trying to figure out how to utilize data locked away in filing cabinets to generate predictive analysis and graphs.



Editor’s Note: 

Learn more about what our developers choose as their everyday tools and what our thoughts on these are:

Comparing React Native to Axway Titanium 

Kotlin: Three Reasons to Start Using it Today 

Node.js – Storing data with MongoDB

From Creative to Tech: 5 Lessons for Mobile Development Project Management

From Creative to Tech: 5 Lessons for Mobile Development Project Management

shockoe-project-manager-Rebecca-mobile-development-project-managementMy journey into Mobile Development Project Management was almost accidental. I started my career in television production, first as a producer on a reality TV show and then jumping into production at a large advertising agency, helping to create television, radio, and video projects for national brands. But after six years of production, I started gravitating more towards the internal management of teams rather than organizing shoots and productions. I decided to give project management a try, and from the minute I felt the warmth in my heart of seeing my client’s multi-media campaign scheduled out across all deliverables, I knew I was home.

When I made the jump to a tech firm six months ago, I discovered several stigmas placed on project managers at creative agencies:

  • They don’t know agile, having worked in a decades-old process that is viewed as slow, clunky, and requiring several layers of approval.
  • They’re only used to working on large, expensive projects, and are unable to follow a tight budget.
  • They’re “snobs” if the work can’t win a snazzy industry award that looks good on a shelf, they’re not interested.
  • They don’t know digital or tech, and they can only work on traditional media (TV, radio, print).

But while there’s some truth and mostly fiction in all of these stigmas, I believe that my experience at that large, clunky agency has given me important lessons and ideas that I incorporate into my mobile development project management on a daily basis. And as more advertising agencies move into 2018 and beyond, agile is becoming more than just a buzzword; consultancies must incorporate more SDLC (Software Development Life Cycle) mobile project management techniques in order to stay competitive and meet their clients’ needs.

With that, here are five lessons I learned that can be helpful to project managers and team leaders in advertising/marketing and tech:

1. Process should help the work get out faster, and evolve and improve it over time
Agile has become something of a buzzword in advertising, and for good reason. Clients are getting frustrated with the time and cost it takes to get work done. But consultancy creatives have several fears about the agile process: that you can’t quantify the time it takes to get the “big idea,” that clients won’t be able to see work in progress throughout and envision the final product, that daily stand-ups would become too much of a time-suck, and that traditional teams should be structured as a copywriter and art director. A large hurdle for an advertising consultancy to get over is to view the work as an evolving piece, and not a finished product. Sometimes that means releasing something to the client or the public if it’s not finessed to the nth degree, or if it has minor bugs. If you’re constantly updating, engaging, and storytelling, then the focus is more on the brand’s journey over time, and less on one 30-second TV spot. Consultancy teams would also benefit from the structure and accountability that a daily stand-up can provide. Responsibilities are made clear, each employee is accountable for the progress and completion of their own work, and the small team is united in their singular mission of getting the work done. And while Project Managers in both industries keep a full list of functionality or deliverables, tech PMs have more of a voice around Sprint Planning, and work with their clients and team members to determine priorities around features, and keep a fluid backlog of “nice to haves” depending on time and budget.

2. Design should improve the experience, not just impress other industry folks
Software Development Life Cycle Mobile project managementAwards are a necessary evil for any consultancy. They’re motivating for employees and serve as PR and sales tools, attracting new clients and making them aware of the consultancy’s work. But one criticism of a creative consultancy is that work is often done for the sole purpose of winning an award, and not serving the consumer. Yet tech companies may often lean in the opposite direction, where design is sacrificed at the expense of functionality and performance. There is a lesson to be learned from both. There is always a place for impeccable design, but its end goal should be to improve the user experience and solidify the consumer’s impression of the brand. As a project manager, that means involving UX/UI designers and developers throughout the lifespan of a project. My most successful projects have started in a room where a designer and developer are both throwing ideas up on the board, and continue collaborating on functionality, navigation, and UX throughout the process, even in QA. But that’s not meant to undercut the importance of a developer because all the smoke and mirrors in the world can’t hide something that doesn’t actually work. This is why in the agile process, we’re not presenting a PDF to the client, we’re presenting a functioning piece of technology. The code isn’t just the “back end” it’s as much of a client-facing deliverable as a design presentation and needs to be as clean, thorough, and documented as the slickest consultancy deck.

3. Strategic Planning can set a foundation for development too
The best advertising campaign is built upon a solid strategic foundation, and a mobile app or tech project should be no different.Functionality shouldn’t be added just because it’s a hot trend– it should make sense for the overall brand and their consumer, and deliver on a business problem the same way a piece of advertising would. One takeaway that a tech company can glean from a creative consultancy is the importance of a creative brief that’s rooted in the overall brand strategy. If the design is always driven by strategy in addition to the normal technical requirements, your projects will never feel like just a string of new functionality with no big picture in sight– which is frustrating for UX/UI designers and developers alike. While sometimes our clients in IT aren’t privy to the marketing plans and decisions of their brands, it’s our jobs to help them create a strategic plan and roadmap that bridges that relationship and creates consistency across all platforms.

4. Saying “Yes” doesn’t mean “Yes, right this minute”
Mobile Development AgencyIn a company meeting recently, our COO Alex was answering questions about timesheets, and stated, “Your nights and weekends should be your own.” I was immediately shocked and felt like applauding (ok maybe I did a little bit). That a statement like that would be shocking speaks to the culture of creative consultancies– you’re expected to be “on call” at all times, and you almost wear your late night and weekend work like a badge of honor. But why? I admit I’m still a bit stumped on this one. Could it be that creatives maintain that conception is not a science, and they can’t predict when lightning will strike? Or that good ideas don’t come until 3 a.m.? Or that marketing clients operate on faster timelines, with emergencies and last-minute media placements popping up quickly? Either way, I have seen some differences after working at a small tech company. UX/UI designers, developers, and project managers all employ “heads-down” tactics that help them to make better use of their time during the day. Also, daily stand-ups and using tools like JIRA and Slack help teams keep tasks prioritized and get work done quickly.

5. But saying “Yes” isn’t a dirty word either
Mobile Development Project Management Creative and Tech One frustration I hear about project managers in IT and tech is that whenever a new idea is raised, the first answer is “No, it’s not in scope.” But if there’s one thing I’ve learned from being an consultancy producer and project manager, it’s flexibility. Saying “yes” is now innate for me, but how do I make sure that we’re protected as a company and not giving away work for free? It’s still a tricky line to walk, but by ensuring my estimates have room for any bugs or issues that naturally occur in development, I can give us and our clients enough space to get it right, not just done. At that point, a new ask from my client begins a conversation: Is this the right piece of functionality for this release, and will the timing work? Will it make this release that much better, that it is worth the extra hustle? With those questions answered, now we can address the budget: How are we doing overall on our hours? Do we have room to add in extra work, or would this addition cause us to go over? By treating a new ask from a client as a conversation and opportunity instead of a disruption, we can reach the goal that’s shared by creative and tech project managers alike: to create work that we all can be proud of.


Note from Editor: 

Our team is all about sharing our “lessons learned” and techniques, here are a couple of other blogs that we think you may find interesting:

Ensure Success with the Right Mobile App Delivery

4 Tips in Designing a Retail Inventory Management App

5 Ways Shockoe Supercharged Mobile Workflow

3 Tips to Start Using Motion in Design

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

The mobile dev world is buzzing with the Axway news that was revealed earlier today. To summarize the announcement:

  • The Axway Appcelerator Indie development tier is now free.
  • Hyperloop is now included with the Indie plan and is now free for all developers.
  • Appcelerator Arrow Builder is now called Axway API Builder and is also included in the (now free) Indie plan.

Hyperloop is Axway’s next-generation compiler that gives Titanium mobile developers full access to the native iOS, Android, and Windows APIs, all from within JavaScript.

Axway API Builder is a tool for creating, managing and orchestrating APIs. It allows developers to expose and control the flow of data from multiple sources using many built-in data connectors. API Builder is also extensible and allows devs to use Node.JS to create their own connectors, flows, endpoints, etc.

Quite simply this means that every mobile developer is only a few JavaScript lines of code away from any native API. Axway is opening the door for mobile developers to have free access to the Axway Appcelerator platform tools including Titanium, Hyperloop, API Builder and more!
Demand for training and developers with experience with both Hyperloop and Axway API Builder will undoubtedly increase as a result of these recent changes. Axway has strategically partnered with Shockoe to develop new training courses for both Hyperloop and Axway API Builder. Shockoe’s development experience with both of these products also enables us to continue giving our clients feature-rich experience, from apps to APIs.

Want to stay connected on all things mobile?


Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.