Embed Size (px)
Citation preview
A Day in the Life of an Application Developer
Rene Vogt-Lowell Technical Education Consultant EMC [email protected]
Paul BrantTechnical Education ConsultantEMC [email protected]
2015 EMC Proven Professional Knowledge Sharing 2
Table of Contents
Table of Figures...................................................................................................5
Abstract ................................................................................................................7
Introduction .........................................................................................................9
Who We Are .............................................................................................................. 10
Dev On - The ascent of the Application Developer ................................................. 11
Plug In, Turn On, Drop Out ..................................................................................... 11
The Application and the Business .............................................................................. 12
The rise of Acquihire ............................................................................................... 12
The 1000X factor .................................................................................................... 12
Who wants to be a Rock Star? - Do you have an Agent? ....................................... 13
The importance of the application ........................................................................... 13
Every Company is a Software Company ................................................................ 14
Need for a new business mindset ........................................................................... 14
Dev On - The Social Developer ........................................................................ 15
Open Source ............................................................................................................. 15
The importance of OpenSource .............................................................................. 16
Driving towards perfection ...................................................................................... 17
Drives 2nd and 3rd Platform Development ................................................................ 18
DevOps ..................................................................................................................... 19
Agile and Lean approaches .................................................................................... 20
Dev On - The Tech Developer .......................................................................... 21
The Art of the Game .................................................................................................. 21
2015 EMC Proven Professional Knowledge Sharing 3
Culture .................................................................................................................... 21
Continuous Delivery ............................................................................................... 21
Lateral Team Movement ......................................................................................... 22
Autonomous Enablement ....................................................................................... 22
Design Principles ....................................................................................................... 22
Management .......................................................................................................... 23
The Design Trifecta ................................................................................................ 25
Scrum ..................................................................................................................... 26
Kanban ................................................................................................................... 26
XP – Extreme Programming ................................................................................... 28
Developer Tools......................................................................................................... 28
Continuous Integration ............................................................................................ 28
Version Control................................................................................................................ 28
Application Mobility .......................................................................................................... 30
Containers ....................................................................................................................... 30
Release Enablement ....................................................................................................... 31
Continuous Delivery ............................................................................................... 33
Infrastructure as Code ..................................................................................................... 35
Measure and Monitor....................................................................................................... 36
APM – Application Performance Management ................................................................ 37
Half-time ............................................................................................................. 39
2015 EMC Proven Professional Knowledge Sharing 4
Dev On - The Communicator Developer .......................................................... 40
Communicators to the nth degree ............................................................................... 41
Relationships - The connections between the data points matter more .................. 41
The relationships between the human points matter even more than that............... 42
Everyone’s affected ................................................................................................ 44
The value of Mentorship ......................................................................................... 44
Brainstorm, Divide, and Conquer ............................................................................... 46
Stakeholders, Target Audiences, and Niche ........................................................... 47
Diverging Convergence .......................................................................................... 48
Requirements vs Desirements ................................................................................ 49
Under-Promise vs Over-Deliver .............................................................................. 50
Gates, Hurdles and Constraints .............................................................................. 50
Think “inside out” of the Box! .................................................................................. 51
Dangerous Waters .................................................................................................. 52
The Big Picture .......................................................................................................... 54
“Nothing for All” vs “Something for Some” ............................................................. 55
Dev On - The Artisan Developer ...................................................................... 55
Meaning ..................................................................................................................... 55
Infinite to MVP: Replicating Ground Zero ................................................................... 56
ArtDev Evolution? ...................................................................................................... 57
Musical Crossover ..................................................................................................... 58
Creative Crowdsourced Explosions ........................................................................... 58
Priceless Art vs Cheap Apps...................................................................................... 59
2015 EMC Proven Professional Knowledge Sharing 5
Bringing it all together ...................................................................................... 61
Music Video Grand Finale ................................................................................ 62
Authors’ Biographies ........................................................................................ 63
Appendix A – References ................................................................................. 64
Table of Figures
Figure 1 - The 3rd Platform .......................................................................................................16
Figure 2: OpenSource Ecosystem.............................................................................................18
Figure 3: 2nd and 3rd Platform comparision ..............................................................................18
Figure 4: Agile vs. Waterfall ......................................................................................................23
Figure 5: Waterfall Process .......................................................................................................23
Figure 6: Agile Developent Process ..........................................................................................24
Figure 7: Design Management Drivers ......................................................................................25
Figure 8: Agile Practices ...........................................................................................................25
Figure 9: The Scrum Process ....................................................................................................26
Figure 10: Scrum Bottlenecks ...................................................................................................26
Figure 11: KanBan Big Board ....................................................................................................27
Figure 12: Extreme Programming Attributes .............................................................................28
Figure 13: Version Control Architectures ...................................................................................29
Figure 14 - Docker (Container) attributes ..................................................................................30
Figure 15: VM's vs Containers ..................................................................................................30
Figure 16: Code Release Flow ..................................................................................................31
2015 EMC Proven Professional Knowledge Sharing 6
Figure 17 - Continious Integration Example ..............................................................................32
Figure 18 - Traditional Production Infrastructures ......................................................................33
Figure 19: Example Orchestration Platforms .............................................................................34
Figure 20: Infrastructure as Code Example ...............................................................................35
Figure 21: Continious Delivery Integration Example ..................................................................36
Figure 22: Measurement of Success .........................................................................................36
Figure 23: APM Approaches .....................................................................................................37
Figure 24: The key to Understanding ........................................................................................41
Figure 25: MineCraft Masters ....................................................................................................44
Figure 26: Divergent Thinking ...................................................................................................48
Figure 27: Example of Analysis Paralysis ..................................................................................49
Figure 28: Inside vs. Outside the Box ........................................................................................51
Figure 29: Myth of Multitasking .................................................................................................52
Figure 30: Google Open Web Submission ................................................................................57
Figure 31: A Day in the Life of an Application Developer ...........................................................62
Disclaimer: The views, processes or methodologies published in this article are those of the
authors. They do not necessarily reflect EMC Corporation’s views, processes or methodologies.
2015 EMC Proven Professional Knowledge Sharing 7
Abstract
Humans have always been long on power and short on thinking about the consequences of
technology influence. In today’s technology driven world, humans who create the intelligence
that runs on computer hardware are becoming important. This is because we rely on intelligent
systems driven by software more and more. This human has a title; they are called Application
Developers.
With statements by visionaries like Marc Andreessen, the creator of the first web browser,
stating “Software is Eating the World”, one can easily see that Application Developers or
AppDevs are becoming even more critical to our way of life.
Therefore, the importance of understanding whom these people are, what, when, why and how
they do what they do is important for all of us to understand.
For example, if an application can be built, there will always be someone who will build it without
contemplating a safer, saner way of doing so, let alone whether the technology should even be
built in the first place. The software then gets written. Who cares where and how it's used?
That's a task for somebody in some corner office.
One also needs to understand the challenges and goals of the AppDevs. There are many
hurdles in the development of an application. For example, what specific functionality is needed
for a release to get the job done? What is that job?
How does an application get distilled from an originally infinite number of possibilities down to a
constrained number of realities based on all the gates, obstacles & constraints AppDevs need to
move through? Do software-defined data centers (SDDC) alleviate some of those constraints?
Do these constraints stifle or induce creativity? These folks often find themselves placed inside
a box while being asked to think outside of it - how do they achieve that?!
What are the processes, practices and tools used by the practitioner?
Do they undergo an artisan process of creating priceless art or just cheap apps?
Quite often, Application Developers are nonchalantly being asked to make or add “just one
simple little update/feature” to a well thought out solution. As a result, this simple change does
2015 EMC Proven Professional Knowledge Sharing 8
not always take into consideration the cohesive masterpiece already created when initially
weighing and balancing all of the original sets of interdependent requirements.
Is this a mere question of a software development life cycle (SDLC) preference? Are we just
talking about Waterfall vs Agile here or do our disposable perspectives on software products,
and the “ease” in which they seem to be modified, risk the creation of “nothing for all” solutions
instead of “something for some”.
Identifying niche needs and limiting the application to solving just these while purposefully
putting on a blind eye to all others is a challenging but important practice for preventing these
“nothing for all” solutions.
What causes AppDevs to reinvent the wheel and drive similar solutions to the same problems
over and over again, each time with the “latest language” and tools? Are either external third
party vendor greed or internal “not invented here” (NIH) syndrome to blame?
Applications need a solid foundation on how they are supported and how the software code
executes its logic. After all, in the world of IT, all of the pieces of the infrastructure like the
network, storage, host processing and supporting services is a means to an end; and that end is
the application.
This Knowledge Sharing article will explain and discuss “A day in the life of an Application
Developer” and all that comes with it.
2015 EMC Proven Professional Knowledge Sharing 9
Introduction
Let us look at a few amazing people; some have called them rock stars. In 1970, a 15 year old
started a business with a friend. They developed a computer program called "Traf-o-Data," an
application that monitored traffic patterns. At the age of 18, he enrolled at Harvard University
thinking of a career in law. The problem was he spent more time in the computer lab than in
class and he eventually dropped out!
In 1996, a 12 year old created a messaging application that his parents used inside their house.
At 18, this person also enrolled at Harvard University. By his sophomore year at the Ivy League
school, he had developed a reputation as the go-to software developer on campus. It was at
that time he built a program called CourseMatch among others. The “others” you might have
heard about. Soon after that, he also dropped out!
It appears that these two individuals had many things in common. They obviously liked
technology and even though they pursued a formal higher education at the same school, that
educational venue did not seem to suit them. They also have one other major similarity.
If I could speak for either of them, I am sure they
would say; “We make beautiful apps!!! ->
I am sure you have heard their names. They are Bill
Gates, who is the richest man in the United States
and Mark Zuckerberg, co-founder and CEO of
Facebook, as well as one of the world’s youngest
billionaires!
Many believe that not only are they or were great
application developers, but they are also respected
and admired around the world.
2015 EMC Proven Professional Knowledge Sharing 10
What then makes these two people as well as millions like them so influential, respected, and
highly compensated for what they do? The answer is simple; they are application developers.
Let us understand what that title “Application Developer” means, why they are
so important, and how they get their job done. As we will see, Application
Developers are really becoming rock stars for many reasons. If John Lennon
was an Application Developer, I bet he would say, “I’d love to Dev
You On”; If you want to jump ahead, check out the
video link on page 61, developed as a complement to this article!
Dev On!
Finally, we will find out what it takes to become one and what the day of an application
developer really looks like.
Who We Are
An application developer is often a computer software engineer, but can have educational
backgrounds much more diverse. Primary responsibilities include developing new types of
applications for computers, mobile phones, and other types of electronic devices.
An application developer would benefit from an advanced understanding of mathematics and of
the binary codes that computers use but those skills are not mandatory. Algorithms, which are
instructional codes used by computers, are created and put through extensive testing to see if
the computers can function correctly based upon the information provided. In most instances,
teams of developers work together and attempt to enhance over time sample applications until
the application reaches a point where it is ready to be marketed.
Developers often make several versions of the same basic application that can be read by
different types of devices, such as cell phones, tablets, and personal computers. Once an
application goes into production, the developer has to work on creating updates to the
application, also known as patches that are released periodically to the public so that the
application can continue to function alongside other constantly evolving types of software. For
example, in order to remain competitive, most software companies hire developers to begin
2015 EMC Proven Professional Knowledge Sharing 11
work on more advanced applications to replace applications that have yet to be released to the
public
Dev On - The ascent of the Application Developer
Not very long ago, developers were often seen as geeky smart people that were too eccentric
and stand-offish to be taken seriously or capable of exerting much influence. We will find out
that has all changed as developers have attained a new status as the real movers and shakers
who hold more power and influence than anyone would anticipate. There is a shift in the role of
the application developer.
The Developer takes a more data-driven, real world look at the new realities facing today’s IT
organizations and the role that development teams play in creating them. A lot has been written
about The Nerd Economy and how it is leading us in a new direction. Developers are now
wielding unprecedented power. Polyglot environments, database fragmentation, and cloud and
open source adoption are only a few of the recent tools used. As developers, they are shaping
product and user experiences in new ways. Organizations that understand and embrace the
value of this shift will be the most successful in the years to come. Today, developers are
becoming one of the most important chattels a business has; regardless of the industry.
Plug In, Turn On, Drop Out
Back in the 1960’s during the hippy movement there where many catch phrases. One was “I’d
love to turn you on”; or how about “Turn on, tune in, drop out”. Today, many want-to-be
application developers are saying “Plug In, Turn On, and Drop Out”. I think we all get the “Drop
Out” part from our friends Bill G. and Mark Z.
However, Billionaire PayPal co-founder and Facebook’s first investor, Peter Thiel, has lately
been making waves by calling a 4-year college education “a bad investment”. He even created
his own fellowship to offer top students $100,000 to drop out of college and become technology
entrepreneurs. In an interview with Morley Safer of CBS’ 60 Minutes, Thiel argues that getting a
traditional college education is no longer needed to be successful. As mentioned, “Mark
Zuckerberg from Facebook didn’t complete Harvard. Steve Jobs dropped out of Reed College.
Bill Gates dropped out of Harvard.”
Many believe that if you do something entrepreneurial, the credentials are not what really
matters. What matters is having the right idea at the right time, the right place.
2015 EMC Proven Professional Knowledge Sharing 12
Cynics believe that good ideas are many and at the same time success stories such as
Facebook are rare. They also believe a college education gives students the full set of skills for
turning good ideas into successful inventions. Others believe that the current education system
restricts the skills needed for success in today’s world. One can go one step further. In a well-
known TED Talk by Sir Ken Robinson titled, “How Schools Kill Creativity”, it states that the
whole process of higher education, stifles creativity. In addition, having a huge student loan
forces many students to take a more conservative and less risky career path.
The Application and the Business
Hiring software developers and computer architects used to be for high tech companies only.
That is no longer the case. Government agencies, shoe manufacturers, and most every other
business vertical you can think of have apps. The venture capitalist Marc Andreessen was
quoted recently that, “Companies are dying for talent. They’re like lying on the beach gasping
because they can’t get enough talented people in for these jobs.”
The conventional wisdom these days states that how computer science is being taught is more
theory and less commercial application, sort of like a trade school approach and the latter is
more beneficial. There are boot camps called “General Assembly”, trying to fill the gap, teaching
crash courses in how to design Web sites and write code.
The rise of Acquihire
It is amazing that quite often the largest corporations are fighting a bidding war for the best
programmers. For example, Christopher Fry, an engineering manager who works at Twitter,
landed a job which paid more than ten million dollars in stock options. To prevent programmers
from jumping ship, there is now a term called Aquihire. This occurs when large companies such
as Google or DropBox spend a lot of money to acquire an entire company in order to get the
application developers. It really does not matter what the acquired company did, they just want
the application developers. In this game, startups have a problem. They do not have enough
money to throw at these developers. Yes, equity can be offered, but there are so many startups,
they are becoming superfluous.
The 1000X factor
Many believe that top application developers are worth their weight in gold. Traditional workers
in a company might be worth three to four times the revenue produced. However, this is in
2015 EMC Proven Professional Knowledge Sharing 13
contrast to an application developer that can create a great application that can generate one
thousand times their compensation. For example, if a developer can create an app that can
support twenty million users, you or a group of developers could potentially create hundreds or
thousands times the revenue for your company relative to your compensation. This is just
another way of saying Dev On!
Who wants to be a Rock Star? - Do you have an Agent?
Traditionally, internal or external recruiters have hired developers and other employees. In
addition, for short-term projects, what is known as “dev. shops” or “body-shops” are out there.
They are consulting businesses that employ engineers or freelancers taking a cut of the billing
rate. Freelancers are not always happy with that since they often get a very small percentage of
the overall billing amount.
The trend now for experienced developers is to get an agent. Agents work with and are paid by
the programmers rather than with the companies actually doing the hiring. The goal is to make
freelancing less risk averse and make it more viable while at the same time making short-term
work cyclical. Having an agent often allows a more balanced lifestyle for Application
Developers. For example, there are companies offering agent services for application
developers like 10X Management and Hack-Match. A company called OfferLetter.io helps
engineers negotiate, and Hired.com lets them market their services, employing “talent
advocates” to help them polish their profiles.
Rock-star developers are, not surprisingly, very different from actual rock stars. Some music
Rock stars have huge egos. Application Developers often have opposite personalities being
more introverted. However, there are similarities. Both rock stars work late hours and often have
a non-traditional life style. In addition, like actual rock stars, rock-star developers come in a
range of personality types. For example, front-end (GUI – Graphical User Interface) designers
and engineers make products that interact with the general public which requires a lot of social
endowment. As a result, they are somewhat with-it and trendy. The further you go down the
“stack,” the more socially challenged a developer can become.
The importance of the application
What is a software application? Application software can be divided into two general classes:
application software and system software. Application software (also called end-user programs)
2015 EMC Proven Professional Knowledge Sharing 14
includes such things as database programs, word processors, web browsers, and
spreadsheets. System software is code that is created that helps end-user software do its job or
it is part of a closed system or appliance. In both cases, underlying hardware, electronic, and
mechanical mechanisms is needed. Therefore, the importance of the application is it usually is
where the intelligence is. Now the application in many ways is becoming not just the
intelligence, but also the business itself. Let us see why.
Every Company is a Software Company
It can be argued that whatever your company does, it really is now a software company. If a
company does not think this way, they are in big trouble! With analytics driving intelligence on
the back end and applications touching customers on the front end, applications are
everywhere. In addition, these new tools are changing how we do business. The result is your
company must, using software and technology, become as responsive and agile as your
customers by measuring, monitoring, evaluating, and responding to data about your products
and services as well as what the impact will be to society. For example, Ford Motor Company
(FMC) drove the 20th-century industrial model.
FMC’s CEO Bill Ford was quoted that when he was growing up he used to worry about making
more cars. Now he worries what if Ford only made more cars? Ford sees cars becoming
“sophisticated computers-on-wheels.” From Wi-Fi receivers that make your car a mobile hot
spot to built-in software that helps increase fuel efficiency; Ford wants to integrate our lives the
same way that Facebook and Twitter are doing today.
Need for a new business mindset
It will be a rocky road for many businesses to embrace this new “life Integration” mind set.
Responsive and agile applications will be the cornerstone in achieving this goal. Businesses
need to work smarter by building organizations that are far more adaptable, inspirational, and
fun. All this drives and creates innovation. The challenge is often changing managements’
approach in making decisions. The leadership style of the 1950’s often no longer works. The
top-down leadership style of the boss telling everyone else what to do no longer works.
Innovative companies create ideas from the bottom up and one can only hope management will
listen.
2015 EMC Proven Professional Knowledge Sharing 15
For example, FedEx, took the approach up front to see that the “Information” or metadata of the
package is as important as or even more important than the shipment itself. This company has
hundreds of developers who build and deploy software products for tracking. Now, FedEx
considers itself a software company that also happens to deliver packages. Going one step
further, FedEx is considering selling its software to other customers and even competitors
making the actual shipping part secondary.
Dev On - The Social Developer
Let’s face it, Social Networking is here to stay. Developers are people too. As a developer, it’s
important to understand how “social” relates to what you are and what you will be doing. The
problem, especially in the enterprise, is how to deliver it in a secure and controlled way. The
goal and benefits is empowering developers to work faster, communicate well, and get
information quickly without constant searches of an ocean of emails. Using Enterprise Social
technologies that enable companies to engage, inform, and connect their employees, partners,
and suppliers is the key. The solution requires:
1. A comprehensive and connected platform – A seamless social experience across many
familiar applications, as well as customers’ data centers, service providers, and the
public cloud, and intelligently mapping interactions to generate personalized insights.
2. A familiar and intuitive user experience – The goal is to improve productivity for users
and better business results. A cloud-based solution that drives faster, lower-cost
implementations reduces the barrier to higher user adoption, which leads to improved
productivity and better business results.
Distributed and mobile workforces are becoming the norm. Being able to obtain input and listen
to all workers wherever they may be is critical.
Open Source
The traditional way of developing software from large software companies like IBM, Microsoft,
and even Apple is developing proprietary software and hardware. For example, mainframes
offered compute power created through a closed approach. Then came the personal computer
running on Microsoft’s software that eventually became the Windows operating system or IBM’s
OS/2 and Apple Computer with various propriety operating systems that over the years
2015 EMC Proven Professional Knowledge Sharing 16
continued this “closed” approach. However, in the 1980’s, the Internet, which had democratic
values and other open initiatives started to loosen the domineering grip, offering choices. Unix
and Linux are examples of an open world. Then came the Open Source initiative.
**What is Open Source? Generally, Open Source refers to a method of creating computer
programs in which the source code is available to the public for use and/or modification from its
original design. Open Source code is typically created as a collaborative effort in which
programmers improve upon the code
and share the changes within the
community. Open Source sprouted in
the technological community as a
response to proprietary software
owned by corporations.
The importance of OpenSource
Open Source is really becoming
important to IT and even EMC. The reason is for developers to address open collaborative
markets and business opportunities including Cloud
Computing, Big Data, Social, and Mobile using
democratized code is now becoming a given. This is also
known as the third Platform. IDC calls the 3rd Platform as
the next big thing beyond PC’s, LAN/Internet, and
Client/Server as shown in Figure 1. For example, EMC,
VMware, and Pivotal are all using Open Source.
In the case of Pivotal, the Open Source Apache Hadoop project was the primary core-code
base of development efforts in Greenplum® big data solutions. Another example is “Cloud
Foundry”, which is a PaaS (Platform as a Service) offering, which is also leveraging Open
Source programming code. In other words, Pivotal’s Big Data and application fabric platform-
development teams use Open Source as the basis or part of its products and solutions. In
addition, not only do they use Open Source, they also contribute code to the public.
How does Open Source work? The open-source model includes the concept of concurrent yet
different agendas and differing approaches in producing software, in contrast with more
Figure 1 - The 3rd Platform
2015 EMC Proven Professional Knowledge Sharing 17
centralized models of development, such as those typically used in commercial software
companies. A main principle and practice of open-source software development is peer
production by bartering and collaboration, with the product, source-material, blueprints, and
documentation available at no cost to the public. Open Source is also a process; even the
military is getting into the Open Source game as outlined in the “Power to the Edge” approach.
Power to the edge refers to the ability of an organization to dynamically
synchronize its actions; achieve command and control and agility; and
increase the speed of command over a network of resources. It is also
an information and organization management philosophy. In effect, it
means getting stuff done more efficiently, faster, and in a more
innovative way than before.
Driving towards perfection
Open Source today is not perfect and has had many challenges. You might think that Open
Source would be highly democratic, distributed, and egalitarian because developers work
together to develop it for everyone else to use. Unfortunately, this has not always been the
case. In reality, even though collaboration and fairness among developers is the goal, many
Open Source software projects have been created and maintained by a privileged few
professional developers. The reasons are many, but most of the issues have to do with
managing the project. To help resolve this management issue, a web-based hosting service
called GitHub was created; it helps the software creation process by making Open Source
development much more decentralized. GitHub made things more personal, democratic, and
easy for developers to become a part of the community and part of the team.
Open Source using GitHub has empowered a new generation of people to collaborate, create,
and produce. GitHub was intended to be an open-software-collaboration platform, but it’s
become a platform for much, much more than code. It’s now being used by artists, builders,
homeowners, and everyone in between, along with entire companies and cities. For example,
people are managing home renovation projects on GitHub. GitHub was once just a place to
store a user’s code, data, and applications; now it’s re-shaping the culture of Open Source.
2015 EMC Proven Professional Knowledge Sharing 18
We are truly living in wonderful times, especially for developers. Open Source is providing an
open, collaborative, and democratic way of producing wonderful software for big data, social
and mobile applications as shown in the ecosystem
outlined in Figure 2. Big companies like Microsoft and other
traditional software vendors may not like Open Source so
much, but they are seeing the light. For example, the all-
powerful and mighty Microsoft is morphing its “.NET”
development platform to be Open Source. They really
have no choice. To keep the hearts and minds of
Application Developers, they have to.
What's essential to understand about OpenSource is it can be shared freely; and as such
becomes very important to social code application development. Social is all about openness
and collaborating in developing applications. In addition, OpenSource is often used in
developing 3rd platform applications as well as the infrastructure that supports it. Let’s look at
what we mean by 2nd and 3rd platforms.
Drives 2nd and 3rd Platform Development
Traditional enterprise
applications such as Oracle are
supported using 2nd platform
infrastructures. Client/Server,
ERM, and Outlook are other
examples of 2nd platform
applications. The 3rd platform is
what’s next!
Web-based applications are
examples of 3rd platform
workloads. Typically, application
developers, especially who are
enterprise focused, need to
support both! That’s why it’s
important for IT infrastructure vendors like EMC and others to support both and offer customers
Figure 2: OpenSource Ecosystem
2nd
Platform
3rd
Platform
Choice
=+
vSphere
vRealize suite
VBlock
vCloud Air
Infrastructure
examples
OpenStack
VMware VIO+ =
Self service
Automated
High Availability
Designed for
failure
Application
level resiliency
Infrastructure
Features+ =
Proprietary or
ClosedSource
Infrastructure
creation/
development
OpenSource+ =
Client/Server
AppsWeb Apps
Figure 3: 2nd and 3rd Platform comparision
2015 EMC Proven Professional Knowledge Sharing 19
and application developers choice as shown in Figure 3. In the enterprise today, 2nd platform
applications are most common. It is the most resilient and often offering self-service and
automation. Examples include VMware's infrastructure solutions shown. In most cases,
application source code is proprietary, also known as Closed Source. For 3rd platform
infrastructures, most of the resiliency is performed by the application itself, with the expectation
that the underlying infrastructure may fail. Examples such as OpenStack and VMware's VIO are
infrastructure solutions. In this case, a lot of the source code is OpenSource! As a result, 3rd
platform infrastructures and applications rely heavily of social code applications development
resources.
Nevertheless, there’s more! Social
Application Development can help us
in three ways. It drives innovation, it
accelerates the creation of applications, and it leverages the
collaborative aspects of crowd sourcing techniques in
a new way. In effect, it can drive higher levels of efficiency in application development.
DevOps
Part of being an Application Developer is to understand the importance of how to work with
other groups within the ecosystem of producing an application. A relatively new approach –
DevOps – is getting a lot of support. DevOps is a term for a group of concepts and approaches
that may not be new, but is being embraced within the application development space. It is
really a framework on how to develop applications. DevOps started out as an approach for
Development and Operations teams to communicate. It now includes the entire development
lifecycle, with the inclusion of automation from the beginning of the process through the
deployment of the solution in a system of incremental, such as that embraced by the Agile
method. This idea has now formed another term, “Continuous Delivery”, which defines a
pipeline approach in releasing applications. This approach has taken hold in many business
verticals, especially for dynamic applications deployed on the Internet.
DevOps is primarily about three things, the Agile Infrastructure, Velocity in application
development, and Lean Startups. The advocates pushing the idea of DevOps are practitioners
using real world experience to help define the transformation of software application
development.
2015 EMC Proven Professional Knowledge Sharing 20
1. Agile Infrastructure. This term is also described as “agile system administration” or “agile
operations”. Its genesis derives from applying newer Agile and Lean approaches to
operations work.
2. Velocity in application development – The second approach is exposed with the
expanded understanding of the value of collaboration between development and
operations staff throughout all stages of the development lifecycle when creating an
application or when operating a service. It also is about how operations are becoming
more important as IT becomes a more service-oriented world.
3. Lean Startup – This approach is to get products into the hands of the customer as
quickly as possible. Many startups believe you just have to bang out some code and
customers will accept it. In reality, having a tight closed loop from building, measuring
the results, and finally learning from mistakes in a concise set of steps is the way to go.
DevOps is also the practice of operations and development engineers participating together in
the entire service lifecycle, from design through the development process to production support.
DevOps is also characterized by operations staff making use many of the same techniques as
developers.
Those techniques can range from using source control, to testing, to participating in an Agile
development process.
Agile and Lean approaches
The old view of operations tended toward the “Dev” side being the “makers” and the “Ops” side
being the “people that deal with the creation after its birth”. The realization of the harm that has
been done in the industry of those two being treated as siloed concerns is the core driver behind
DevOps. In this way, DevOps can be implemented as an outgrowth of Agile – agile software
development prescribes close collaboration of customers, product management, developers,
and (sometimes) QA to fill in the gaps and rapidly iterate toward a better product. DevOps is
simply extending Agile principles beyond the boundaries of “the code” to the entire delivered
service.
2015 EMC Proven Professional Knowledge Sharing 21
Dev On - The Tech Developer
As previously discussed, the social aspect is very important in application development. The
question is, how do you achieve these goals? The answer is often through using the right set of
tools. These tools are not just technology-based like IDE’s (Integrated Development
Environments) and source code version control systems. Let’s find out what they are.
The Art of the Game
For many, Application Development is considered an art. In creating art, there are a number of
principles in doing so. Again, DevOps is leading the way.
Culture
A DevOps culture is one created through discussion and
debate. Traditionally, siloed technical teams interact through
complex request procedures, which may require director-level
arbitration. A more DevOps approach talks about the product throughout its lifecycle, discussing
requirements, features, schedules, resources, and whatever else might come up. The focus is
on the product, not individual agendas. Production and build metrics are available to everyone
and prominently displayed.
Responsibility and variety of roles is another key attribute of DevOps. For example, one of the
early controversial aspects of what has become DevOps is the affirmation that Engineering
should be doing on-call rotations. This way, developers would see personally how their
application is performing which is often the best feedback method. In this way, the people who
are empowered to directly make an improvement are the ones who are alerted to the defect.
Additionally, using these approaches, the team is incentivized around your core goal: creating
an awesome product for your customers, whatever that product happens to be.
In this way, development is not rewarded for writing lots of code. Operations are not punished
when not all that code runs as expected in production. The team is rewarded when the product
is amazing, and shares in the improvement process when the product could be more awesome.
Continuous Delivery
Another principle to adhere to is embracing and incorporation of
2015 EMC Proven Professional Knowledge Sharing 22
Continuous Delivery, which includes integration, test, and QA. It is important to make sure the
software is always in a releasable state so that deployment is a simple process, which can be
accomplished on demand.
Lateral Team Movement
Another principle that should be actively encouraged is lateral movement between functional
teams. When IT practitioners move from one functional team
to another, cross-pollination occurs, bringing valuable
information about processes and challenges with them.
All team members should respect all other team members. This might be stating the obvious,
but often it is not the case. Everyone needs to recognize the contributions of all and treat each
team member appropriately. Respectful discussion and listening to other’s opinions is a learning
experience for everyone.
This then leads to trust. Trust is a massive component of achieving a DevOps culture.
Operations must trust that Development is doing what they are because it is the best plan for
the success of the product. Development must trust that QA is not really just there to sabotage
their successes. The Product Manager trusts that Operations is going to give objective feedback
and metrics after the next deployment. If any one part of the team does not trust another part of
the team, often the tools will not work.
Autonomous Enablement
Allowing the development and operations teams to decide which
tools to use drives inclusion and empowerment offering various
levels of autonomy. With today’s open and collaborative
environment, letting the team Choose Its Own Tools is often a viable approach. In addition, if
the members of the team build the infrastructure and apps they want, they are more likely to
stay invested in their work which allows focus on development, which is the ultimate goal.
Design Principles
Application Developers are designers. As such, like any other creation process, having a set of
principles to adhere to is critical. From managing through execution, let’s see how it is done
.
2015 EMC Proven Professional Knowledge Sharing 23
Management
When creating applications, there are various software
project management practices available to a
development team. Two of the more well-known
practices are called “Waterfall” and “Agile” as shown in
Figure 4. The Waterfall model can essentially be
described as a linear or continuous model of software
design. The Agile model is more of an iterative approach
with limited features added per iterative cycle. Let us
take a closer look at Waterfall.
Waterfall employs a sequential design process as shown in Figure 5. Development flows
sequentially from a start point to end, with several different stages: Conception, Initiation,
Analysis, Design, Construction, Testing, Implementation, and Maintenance.
The emphasis of Waterfall is the project plan and therefore before beginning any kind of
development, there needs to be a clear strategy and a clear vision. Because the Waterfall
method requires upfront, extensive planning, often the execution risks can be reduced. The
ability to estimate timetables and budgets more accurately is also another advantage with
Waterfall potentially addressing risk concerns.
In addition, Waterfall development processes tend to soften the loss of team members since the
Waterfall method inherently requires extensive planning and documentation. A new designer
can easily take the old designer’s place, following the development plan without a problem.
What then are the
disadvantages of
Waterfall? It’s extremely
rigid and inflexible. Altering the
project design at any stage in the project can increase the likelihood of delays. Quite often, it is
nearly impossible to make changes to the solution. As a result, a requirement of the Waterfall
design approach is the ability to gather all of the requirements upfront. In addition, another
problem with the Waterfall method is that feedback and testing are deferred until very late into
the project thus reducing feedback on development results. Therefore, if there is a problem, it is
Figure 4: Agile vs. Waterfall
Figure 5: Waterfall Process
2015 EMC Proven Professional Knowledge Sharing 24
very difficult to respond to it, requiring a substantial amount of time, effort, and a potential for
lost business opportunities.
In contrast, the Agile method as shown in Figure 6, proposes an incremental and iterative
approach to software design. It was essentially developed in response to the limitations of
Waterfall, as a way to give designers more freedom. The design process is broken into
individual
modules that
application
developers work
on. There is no
pre-determined
course of action or plan with the Agile method. Rather, developers are free to respond to
changes in requirements as they arise and make changes as the project progresses. The
practice of Agile development is relatively new in development of software applications.
However, it has made substantial gains in use over the last few of years. Let us look in more
detail of the advantages and disadvantages of this design approach.
The advantages to Agile are it offers a highly flexible design model, promoting adaptive planning
and evolutionary development. Agile might be described as freeform software design. Software
developers work on small modules at a time. Customer feedback occurs simultaneously with
development, as does software testing. This has a number of benefits, especially in project
environments where development needs to be able to respond to changes in requirements
rapidly and effectively.
Agile can be especially beneficial in situations where the end-goals of projects are not clearly
defined. For example, if you are working with a client whose needs and goals are a bit hazy, it is
probably worthwhile to employ the Agile method. The client’s requirements will likely gradually
clarify as the project progresses, and development can easily be adapted to meet these new,
evolving requirements. Lastly, this method also facilitates interaction and communication.
Because interaction among different developers and stakeholders is common, it is especially
conducive to teamwork-oriented environments. Different developers work on different modules
throughout the development process and then work to integrate all of these modules into a
cohesive solution.
Figure 6: Agile Developent Process
2015 EMC Proven Professional Knowledge Sharing 25
Though highly flexible, Agile simply does not have the structure that the Waterfall method has
and this does present some drawbacks. Agile projects tend to be hard to predict, from timelines
to budgets. Without a concrete plan, everything remains a bit vague and nebulous.
In addition, as previously discussed, active user involvement and intense collaboration are
required throughout the Agile process. Even though collaboration can be considered a positive,
it does have some negative aspects. For example, highly collaborative development methods
can be quite time consuming, much more so than the Waterfall method due to not having a
concrete plane. More brainstorming and dialog often occurs.
What then is the best
development process for
implementing a DevOps
approach to Application
Development? What are the drivers?
The common drivers are shown in Figure 7 such as customers and requirements changing as
well as technology innovation. The most common answer is with constant and accelerated
changes in business requirements, customers’ needs, and technology innovations, an agile
approach is often the recommended and proper approach. Waterfall tends to be best for static
projects, where it is not likely that many changes will be made throughout the development
process. In contrast, Agile tends to be a better option for dynamic projects where changes are
likely to be made during the design process pipeline.
The Design Trifecta
Let’s look closer at the Agile process. Creating a shorter
design cycle has its benefits; however, with a more agile
build and test cycle, a number of bottlenecks can arise. For
example, the development team can write some great code
but, if they decide to do faster design, build, and test
iterations, they might be wasting time waiting for other teams
to complete their tasks in QA or test. In other words, how do
teams address bottlenecks in the cycle? This is where
Scrum, Kanban, and XP, also known as extreme
Figure 7: Design Management Drivers
Figure 8: Agile Practices
2015 EMC Proven Professional Knowledge Sharing 26
programming comes into play as shown in Figure 8. Each of these approaches is different but
related. Let us go over these agile practices and approaches.
Scrum
The Scrum method of agile software development as shown in Figure 9, is associated with a
regular, repeatable work cycle, known as a sprint or iteration. A sprint is typically about 30 days
long, shorter sprints, such as one-week, two-
week, or three-week sprints are also
common. How long each sprint lasts is
something for the team to decide. The team
must weigh the advantages or disadvantages of a
longer or shorter sprint for their specific development
environment. The important thing is that a sprint is a consistent duration. During each sprint, a
team creates a shippable product, no matter how basic that product is. Working within the
boundaries of such an accelerated timeframe, the team would only be able to build the most
essential functionality. However, placing an emphasis on working code motivates the product
owner to prioritize most essential features of a release. This flow encourages developers to
focus on short-term goals and gives customers a tangible, empirically-based view of progress.
Because a release often requires many sprints for satisfactory completion, each iteration of
work builds on the previous. This is why Scrum is described as “iterative” and “incremental.”
Kanban
When adhering to a scrum iteration process, often bottlenecks arise as shown in Figure 10. A
software development process can be
thought of as a pipeline with feature
requests entering one end and improved
software emerging from the other end.
Inside the pipeline, there will be some form
of process, which could range from an
informal ad hoc process to a highly formal
phased process. In this case, a simple
phased process of: (1) analyze the
requirements, (2) develop the code, and
Figure 9: The Scrum Process
Figure 10: Scrum Bottlenecks
2015 EMC Proven Professional Knowledge Sharing 27
(3) test that it works is outlined. It could also be a more formalized Scrum sprint as well. A
bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the
throughput of the bottleneck. The effect of this bottleneck is that lead times go up. In addition,
work sitting in the pipeline ties up investment, slows time to market ,and often quality suffers. To
keep up, the testers start to cut corners. The resulting bugs released into production cause
problems for the users and waste future pipeline capacity.
If we knew where the bottleneck was, we could redeploy resources to help relieve it. For
example, the analysts could help with testing and the developers could work on test automation.
However, how do we know where the bottleneck is in any given process? In addition, what
happens when it moves? This
is where Kanban comes in. A
Kanban system, in its simplest
form, consists of a big board on
the wall with cards or sticky
notes placed in columns with
numbers at the top as shown in
Figure 11. The numbers at the
top show the maximum number
of work efforts being allowed within each process
step such as pending, Analysis, Development, and so on.
This allows the development team to see at a high level what is going on in process flow.
Limiting the work-in-progress at each step reveals the bottlenecks so the team can address
them. The cards represent work items as they flow through the development process
represented by the columns. The numbers at the top of each column are limits on the number of
cards allowed in each column. The limits are the critical difference between a Kanban board and
any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the
process prevents overproduction and reveals bottlenecks dynamically so that you can address
them before they get out of hand.
Figure 11: KanBan Big Board
2015 EMC Proven Professional Knowledge Sharing 28
XP – Extreme Programming
Extreme programming (XP) has many facets and there is a lot of overlap with Scrum and
Kanban in the outcomes they derive. Techniques such as pair programming, coding standards,
and small incremental releases are included as shown in Figure 12.
However, one aspect of XP that is unique and complementary
to the others is the aspect of customer interaction. XP is
successful because it stresses customer satisfaction. Instead
of delivering everything you could possibly want on some date
far in the future, this process delivers the software you need
as you need it. XP empowers developers to confidently
respond to changing customer requirements, even late in the
development life cycle.
Extreme Programmers constantly communicate with their
customers and fellow programmers. They keep their design
simple and clean. They get feedback by testing their software
starting on day one. They deliver the system to the customers as early as possible and
implement changes as suggested. Every small success deepens their respect for the unique
contributions of team members. With this foundation, Extreme Programmers are able to
respond quickly to changing requirements and technology.
Developer Tools
Anyone who develops or creates something usually has a set of tools. This is also true of an
Application Developer. Let’s look at some of the most common tools they use.
Continuous Integration
Most developers understand and appreciate version control as it relates to source code. Being
able to save previous versions and releases is a well-known process for most developers.
Version Control
A day in the life of any developer involves version control.
Version control allows developers to manage source code
updates and changes in a logical way. However, it is
Figure 12: Extreme Programming
Attributes
2015 EMC Proven Professional Knowledge Sharing 29
important to appreciate that version control is not just about source code. It’s best practice to
use version control for all production artifacts. This makes it easier for testing and
troubleshooting with changes made during production repeatedly in a reliable, low risk way.
Looking deeper into source code management, automation software tools supporting this
function have been used for years in the management of source code in developing
applications. Source code management software creates checkpoints in one’s work and allows
you to go back to those checkpoints when you want. Once you are back to such a checkpoint,
you can also deviate from the original path that you chose. This is exactly what version control
systems do for you.
As shown in Figure 13, when using version
control, the main code is present either locally on
a shared development platform or on one central
repository using a client-server model or
distributed over many repositories. Local shared version control systems such as “CVS” have
been around the longest and used infrequently given multiple limitations in today’s agile world.
Distributed and/or client-server models are used most often. Centralized systems such as
“subversion” have a single central copy of the code on a server and developers commit changes
to this central copy only. In distributed systems such as “Git”, every user has a copy of the code,
with full history of the project. Subversion’s strength is emphasis on centralized code and RBAC
(Role-based access control), which can be important in an enterprise environment.
Git offers strong support for non-linear development more in line with the Agile or DevOps
approach to collaboration and openness. Git supports rapid branching and merging and
includes specific tools for visualizing and navigating a non-linear development history.
Now that we have manageable code, let us look at the best way of moving from development,
through test, and into production, adhering to the DevOps model of collaboration and
transparency.
Figure 13: Version
Control Architectures
2015 EMC Proven Professional Knowledge Sharing 30
Application Mobility
Most applications are dependent on services, such as a particular operating system, database,
infrastructure architecture, or cloud provider. The challenge then is how does one allow the
application to be easily moved from one infrastructure to another? The answer is containers.
The concept of an application container is not new; examples
include LXC, Vagrant, and others. What is new is how the
container is being designed. This new container is unique in
several ways: it is based on Open Source, which prevents
vendor lock-in, it is lightweight allowing you to massively
scale, and it is backed by some big players, such as
Google and Facebook. For example, Docker is an
example of a container technology that is gaining wide
acceptance. Docker is being embraced by more than just
the Linux open source- based proponents. Proprietary
software companies such as Microsoft have also
incorporated Docker.
By using containers, without making any changes to the application itself or its configuration,
applications can run within one’s development, test, and finally a production environment. In
addition, one can move to any infrastructure environment, be it on a private, hybrid, or public
cloud. An example of a container is “Docker”. Docker does three things as shown in Figure 14.
First, it allows developers to create applications that are very small, allowing millions of
instances to run on a smaller infrastructure
footprint. Second, it allows applications to be
moved anywhere in the cloud at the flip of a
switch. Last, it allows the application to scale
and ensure it is always running and available.
Let us see how this is done.
Containers
Docker containers, as an example, have similar
attributes to VM’s or virtual machines. What then is the difference between containers and
Figure 14 - Docker (Container) attributes
Figure 15: VM's vs Containers
2015 EMC Proven Professional Knowledge Sharing 31
virtual machines as outlined in Figure 15? VM hypervisors, such as ESX, Hyper-V, KVM, and
Xen, are all "based on emulating virtual hardware”. That means that there is a lot of legacy code
and services in terms of system requirements.
Containers, however, use shared operating systems. This offers increased efficiency compared
to hypervisors in terms of system resource. Instead of virtualizing hardware, containers rest on
top of a single Linux instance. This in turn means you can eliminate a high percentage of the
ancillary code leaving you with a small, neat capsule containing your application. As a result, the
number of server application instances can be substantially increased as you can use Xen or
KVM VMs on the same hardware. The time of creation and deployment of each application is
increased.
Docker is built on top of LXC. The key difference between containers and VMs is that while the
hypervisor abstracts an entire device, containers just abstract the operating system kernel. This,
in turn, means that one thing hypervisors can do that containers cannot is to use different
operating systems or kernels. With Docker, all containers must use the same operating system
and kernel. If multiple copies of the same application are what you want, containers is the best
option. The advantage of using containers is with the efficiency it offers, data center or cloud
providers can save tens-of-millions of dollars annually in power and hardware costs.
Release Enablement
The life of an application developer does not end with code development. It is important to be
able to understand what features and functionality are part of every release. Automating this
process with a single repository of the deliverables is the key for automated release processes
and is very important as shown in Figure 16.
Releasing software to a target system is always
a synchronization point for the software itself,
the infrastructure, and the development and
operations teams. Often, “done” is considered
exactly that: the point at which the software has
been successfully deployed and configured to a
target system. Under automatic releasing, major
parts of the release process are performed by scripts and tool chains. A simple single action to
Figure 16: Code Release
Flow
2015 EMC Proven Professional Knowledge Sharing 32
promote automatically created release candidates to release status is the ultimate goal. To gain
fast feedback and synchronize across departments continuously, scripts and tool chain support
is required. The prerequisites of a holistic automatic releasing process include the following:
Having team commitment in collaborative working environments is critical. One must use highly
integrated tool chains consisting of lightweight tools such as Jenkins, Sonar, and Maven, that
can be chosen and orchestrated as needed and that are aligned with specific requirements.
Another key approach to release management is to include source code, database scripts,
middleware, infrastructure, configuration files, such as Java properties files, and build/deploy
scripts into version control. Using declarative formats to set up the automation and releasing
process, wherever possible makes management and modifications less restrictive when doing a
release. Another best practice is to Declare, explicitly, and isolate dependencies of
application, middleware, and infrastructure. Finally, it is important to integrate all
artifact types, including source code, database scripts, and infrastructure scripts
into a single repository.
Let’s look at automated release management that is all part of a
Continuous Integration (CI) and coupled tightly to a
Continuous Delivery process.
Using standards and tools that
are native to the development
and target platform currently in
use is often a good idea when
setting up a holistic software delivery
process. With the following example as
shown in Figure 17., lets illustrate how to use a container construct for the software being
developed and to configure the installed (or updated) application during installation time.
An example of a development or delivery process for Linux-based target systems using RPMs
as the container for the software is shown in Figure 17. As a part of a continuous build, the
developer pushes code (Step 1) to the version control system or Source Control Manager
(SCM), in this case Github. The SCM then notifies the Continuous integration and delivery
server, in this case Jenkins, to pull a code branch (Step 2). Jenkins then checks out source
Source Control
Manager (SCM)
1 - Push updated
Source Code
Continuous
Integration/Delivery
Server
Developer
2 – Notify CI engine to
pull code branch
3 – Pull code
Branch request
4 – Git replys with
code branch
5 – Build
Binaries
Build Repository
(RPM, EARs, etc)
Figure 17 - Continious Integration Example
2015 EMC Proven Professional Knowledge Sharing 33
code branch (step 3) and builds scripts from a version control system or SCM. The SCM system
then notifies Jenkins with a code branch to build upon (Step 4). Jenkins then uses a build
repository to create delivery packages in the form of RPM’s (Red Hat Package Manager) or
EAR’s (Enterprise Archive) files (Step 5). Continuous integration, test-driven development, and
Build automation are not new to DevOps. All of these had a purpose to automate as many parts
as possible of a software product lifecycle. However, the focus of DevOps is often the software
itself, and the infrastructure on which the software runs is still quite often a “work in progress”.
Continuous Delivery
Traditionally, deployments within a
typical production infrastructure had to
do with the configuration of storage,
operating systems, servers, switches,
routers, and firewalls each with its own
separate team managing and monitoring
as shown in Figure 18. Documentation of
the environment has often been limited.
Figure 18 - Traditional
Production
Infrastructures
2015 EMC Proven Professional Knowledge Sharing 34
Given the dynamic nature of Development environments, even close to the period of
deployment, often the architecture is not yet fixed. It is also common that each developer has
set up his or her local development environment with all the components running on one or two
development machines. This leads to different development, test, and production configurations.
To make matters worse, there is also often no central version of the infrastructure that can be
considered always
stable. An approach
to address these
challenges is to
consider the
infrastructure as code
itself. Implementing
this form of
methodology allows a
simplified way of
managing the
infrastructure through
abstracting the underlying
hardware resources. Let us take a closer look.
As previously discussed, deploying an application within a test or production environment often
has been hand-crafted, with scripted solutions and limited documentation. If you embrace the
approach of abstracting the infrastructure as code, the ability to automatically release
applications is enhanced. In recent years, tools in the field of configuration management started
to gain popularity to address these challenges based on well-documented RESTful API’s. These
tools help developers and operations work together and enable more transparency on the
infrastructure level. After all, in today’s world of ever more complex and distributed IT systems,
there is an increasing need for developers to know about the operational aspects. The
infrastructure-as-code paradigm, also known as a software-defined data center and its related
tools can help to achieve this goal.
As shown in Figure 19, by leveraging various orchestration platforms such as vCloud Director
from VMware and OpenStack and the underlying compute, network, and storage abstraction
API’s such as EMC vIPR and VMware NSX, make the infrastructure truly look like code.
Figure 19: Example Orchestration Platforms
2015 EMC Proven Professional Knowledge Sharing 35
Infrastructure as Code
By treating the infrastructure as code, flexibility between how the infrastructure is used and
shared in development, test and
deployment is now possible. As
shown in Figure 20, the infrastructure
as code approach helps to further
the spread and integration of many
tools such as Puppet and Vagrant
and grow the whole community
around them. Vagrant allows one to
easily build lightweight and portable
virtual environments, based on a simple
textual description. Puppet is a configuration
management tool that uses a declarative syntax to describe the desired state of a target
environment and allows this description to be executed to create that state on a target machine.
In this way, developers do not have to set up the environment manually or partly aided by
scripts, but can have those writing executable specifications, utilizing virtualization to create and
destroy their test environments on the fly, as needed. Getting new developers on board would
simply be a matter of having developers check out the specification from the version control
repository, execute it, and use the same environment as their other team members. If the team
decides that changes to the infrastructure have reached a stable level, the specification can be
used to update any shared environments such as for acceptance or integration tests. Once that
is done, it can be passed over to the operations team, who can reuse the specification for
staging and production environments.
Figure 20: Infrastructure as Code Example
2015 EMC Proven Professional Knowledge Sharing 36
Figure 22: Measurement of Success
Finally, as the example shows in Figure 21, Jenkins, in conjunction with provisioning software
such as Vagrant and Puppet or Chef, can push the software code to the target platform, tests
can be done and, once done, the
environment can be completely torn down or
remain and scale accordingly in a production
environment.
DevOps tools offer the connection between
the traditional approach of SDLC
development and the operational focusing
only on the current released application,
middleware, and infrastructure instance.
The software-defined data center (SDDC)
bridges that gap allowing abstraction of the
underlying operational models.
In addition, the SDDC emphasizes the need to handle set up of the infrastructure in the same
way you would handle development of your code: pick the right language or tool to do the job
and start developing a solution that suits your needs, making it an executable specification that
can be applied to target systems efficiently and repeatedly. This can be achieved by using tools
such as VMware vCloud Director, vCAC, and vCloud
Suite. In addition, there are also open source tools such
as Vagrant, for managing virtualized development
environments, and Puppet or Chef, which are tools for
managing infrastructure items.
Measure and Monitor
One of the most important concepts of an application
developer adhering to a DevOps approach is to measure
and monitor the ability for applications to deliver business value. How does one measure
success in that regard? One way, as shown in Figure 22, is to evaluate the number and frequency
of software releases. Another is to determine the number of defects per release or the time or
cost of each release as well as the time it takes to fix defects, also known as the Mean Time To
Figure 21: Continious Delivery Integration
Example
2015 EMC Proven Professional Knowledge Sharing 37
Repair (MTTR). Performance of the application also should be measured. From a business
perspective, understanding the impact of releases from a revenue or profit perspective is also a
criteria of measurement.
APM – Application Performance Management
In line with the DevOps process flow, Application Performance
Management (APM) is the monitoring and management of
performance and availability of software applications. APM strives to
detect and diagnose application performance problems to maintain an
expected level of service. The goal of APM is the interpretation of IT metrics into business
meaning and value.
One metric is the performance experienced by end users of the application such as average
response times under peak load. The load is the volume of transactions processed by the
application, e.g. transactions per second (tps), requests per second, and pages per second. The
response times are the times required for an application to respond to a user's actions at such a
load.
Another metric is the computational resources
(CPU, memory, IO) used by the application for
the load, indicating whether there is adequate
capacity to support the load, as well as
monitoring possible locations of a performance
bottleneck. Measurement of these quantities
establishes an empirical performance baseline
for the application. The baseline can then be
used to detect changes in performance.
Changes in performance can be correlated with
external events and subsequently used to predict future changes in
application performance. In order to monitor application performance, solutions exist to
automate the process of mapping transactions and applications to underlying infrastructure
components as shown in Figure 23.
Figure 23: APM
Approaches
2015 EMC Proven Professional Knowledge Sharing 38
When preparing to implement a runtime application architecture, it is necessary to ensure that
up/down monitoring is in place for all nodes and servers within the environment (aka, bottom-up
monitoring). This helps lay the foundation for event correlation and provides the basis for a
general understanding on how network topologies interact with application architectures.
Monitoring business transaction is also important. It is also important to arrive at a common set
of metrics to collect and report on for each application, then standardize on a common view on
how to present the application performance data. Collecting raw data from the other tool sets
across the APM model provides flexibility in application reporting. This allows for answering a
wide variety of performance questions as they arise, despite the different platforms each
application may be running on. Too much information is overwhelming. That is why it is
important to keep reports simple or they will not be used.
2015 EMC Proven Professional Knowledge Sharing 39
Half-time
You’ve read about the Social and Technological aspects of application developers’ lives. This
first half covered their logistical intelligence, the left brain, concerned with the organization
of the user experience. Now we shift focus to their emotional intelligence, the right brain,
concerned with the passion of the human experience. A Day in the Life of an Application
Developer continues now with the Communication and Artisan sides of this interesting creature
with some hopefully helpful philosophical insights along the way – Dev On!
Just like the college dropouts previously mentioned, AppDevs often “drop-out” of the status quo
and seek to add value where value was once missing. Many AppDevs are dropping out of a 4-
year college education because they feel it’s “a bad investment” to spend more time on theory
than on application (pun definitely intended). They are also dropping out of a job because
management is forcing them to spend more time on mass-producing broken widgets than on
fixing them, or dropping their own children out of a school system because (like Sir Ken
Robinson’s assessment) they feel said school system spends more time on standardization
than on cultivating their child’s unique creativity. AppDevs often recognize that once an idea is
abused past its original intent and starts devaluing humanity, it is time to be painfully honest with
ourselves, till the soil, and re-innovate. As stated earlier, quite often, the most innovative ideas
are created from the bottom up starting with an individual’s creative solutions and not from the
top-down starting with an organization’s consumption model for their consumers. Sometimes
even great ideas become overused, imitated, and saturated by others in a non-optimum way.
For example, in the technology world, everything is a disruption. Everyone wants to be a
disruptor. However, there is nothing uniquely righteous about disrupting, either as a way of
changing the world or as a way of getting rich.
When enough people have applied a great idea as the proverbial hammer towards too
many non-nail problems, the idea can not only begin to lose its original value but also begin
to devalue the human experience as well.
2015 EMC Proven Professional Knowledge Sharing 40
At this point, AppDev’s are often the first to recognize the need to create new solutions for
today’s problems instead of blindly continuing to consume yesteryear’s innovations.
In an IdeaMensch interview with Akhil Nigam
(http://ideamensch.com/akhil-nigam/), Founder
and President of MassChallenge
(http://masschallenge.org/about/vision), the world’s largest
accelerator program and startup competition, Akhil illustrates the
importance of creating new, instead of re-allocating existing, value:
“The MassChallenge epiphany came to [us] in 2009 … At that
moment everyone was focused on the worst global
economic downturn since the great depression. Risk was fleeing
everywhere and the whole economic system came to a standstill with
nobody risking any capital or even lending capital. Our basic premise
was that startups are the source of a majority of the value creation in
society and we need to focus the society more towards value creation
rather than just financial engineering. Too many people and
organizations were taking slices of the pie, and not creating more
pies.” When there is not enough pie for everyone, AppDevs are
usually the first to roll-up their sleeves, put on their chef’s hat and
feed the people. To achieve this, they blend and balance logical
emotion, objective subjectivity, reasonable intuition, and diverging
convergence while being passionate communicators of the ideas that
result from brainstorm sessions with these seemingly opposing paired forces. They apply the
best of these ideas with compassion toward the human experience they intend to elevate. Enter
the Communicator & Artisan Developers.
Dev On - The Communicator Developer
Great communication applies more to the ears/eyes and less to moving mouths. Great coding
applies more to the ears/eyes and less to moving fingers. A day in any application developer’s
life is sure to contain volumes of communication and a wise AppDev understands the
importance of throttling their input to a higher rate than their output. Why? Because to add
2015 EMC Proven Professional Knowledge Sharing 41
value, they first need to learn where value is missing and to learn where value is missing, they
first need to observe their fellow humans in their natural environment.
Communicators to the nth degree
What are people in their department complaining about? Are the problems they are
experiencing technological, procedural, or political? Which technology? Which process? Which
personnel? Why? What have they tried to do about the problem? Have they asked any of their
peers or management for help with this problem? Whom have they asked and what was the
response? How long has the problem existed? Is this particular problem a resurrection of an
earlier problem? Was that earlier problem resolved with alternate technology, process, or
personnel? Which specific one was used? What is the political climate of the department, of the
parent institution? Do people seem afraid to bring up the problem? Was any specific employee
ever blamed for the problem? Did an employee get sent to HR for anger management over the
problem? Does management understand the problem? How does the department rank the
problem in terms of priority?
The scenario above might depict an AppDev’s
problem-solving thought process while
specifically at their job, but AppDevs tend to
generally employ the same nth degree
observation and curious question asking of their
fellow humans in any scenario: at work, while
commuting, during family time, at a party,
wedding, or funeral. The best communicators
keep in mind that many people, problems, and
solutions have come before them and before
attempting to add their own value, they must first
seek to understand and learn from history as shown in Figure 24. The key is to reveal and listen
and finally understand.
Relationships - The connections between the data points matter more
Newborn AppDevs often start-off “reinventing the wheel”. Although we often
hear this phrase uttered with a negative connotation, there is a certain value
of re-achieving someone else’s previous great achievements. You gain an
Figure 24: The key to Understanding
2015 EMC Proven Professional Knowledge Sharing 42
understanding of the problems; compassion for those affected; respect for the solutions’
authors; humility for the magnitude of the solutions’ endeavors; confidence through re-achieving
the solutions yourself, and insights into their potential flaws, limits, and re-applicability.
Once a newborn AppDev becomes a toddler, they are presented with a choice. When they
discover that they can walk (on code :-), they can;
1. Choose to continue creating their own wheels from scratch in Play
Dough or
2. They can learn to connect ready-made ones with other pre-existing
building blocks available in inter-connectable Lego kits.
The first choice retains the ego, the need for control, the need to verify
everything, and a fear of the unknown. When AppDevs succumb to this first
choice, too high an emphasis can often be misplaced on the individual
technology data points themselves than on the more richly valuable relationships between them.
When these relationships are missed altogether, a siloed, solitary, and fragmented
existence results. Roadblocks to innovation are erected and the user experience …
suffers.
The latter choice requires embracing community awareness, trust, collaboration,
and exploration. When AppDevs make this second choice, the relationships
between the data points are uncovered and magnified as the most valuable.
Interconnected roads, bridges, and high-tech recreational vehicles are meshed out of once
disparate pieces of innovation and the human experience … prospers … as we drive IT
together.
The relationships between the human points matter even more than that
The two choices above seem to be less of an issue with the Net Generation (Net Gen) than with
previous ones. Net Gen, also known as the iGeneration, Gen Tech, Gen Wii, Gen Next, Post
Gen & Generation Z, was born into an electronic world of infinite possibilities. They seem to
have been exposed more to the abundance produced through creative collaboration and less to
the scarcity produced through economic paranoia. One only has to look at the numbers of
Minecraft Net Geners to notice this mind-shift at play.
2015 EMC Proven Professional Knowledge Sharing 43
In Minecraft, the Net Gen version of the Lego kit, Net Geners are often iassuming the roles of
teacher, student, creator, and virtual colleague alongside the obvious role of player while
making things out of virtual building blocks. Early immersive game-play like this instinctively
breeds the Communicator AppDev values of the previous second choice in this generation
(community awareness, trust, collaboration, and exploration), invalidating the need to ever
consider the first at all! Much can be learned from these young AppDevs. I originally phrased
the previous sentence with the words future AppDevs but the truth is, they have been behaving
like guru AppDevs for years now, minus the income producing jobs while most of these little
gurus are still at home, so let’s just call them young AppDevs). If you observe them at play,
you eventually notice how much value these AppDevs place on the relationships between the
data points. The choices they make do not pertain to which network connection (WiFi,
Bluetooth, Cat5) or which client device (Android phone/tablet, iPhone/iPad, Chromecast,
Desktop, Xbox, Playstation, Amazon Fire TV) or which programming language ii(Java, straight
Javascript, ScriptCraft) is technologically superior while playing the game. They’re not
concerned with the idea that one technology might eventually supplant another nor do they
spend time worrying which is the most industrially and politically stable one to align with for their
creative endeavors. Should one of these options disappear, these kids will probably be the ones
creating a better solution as they have fun doing it – together! The main choices they make are
based on the questions they ask and answer about the relationships between the data points
affecting gameplay. Sampling my own kids’ conversations with their friends:
“Which server is less ‘laggy’ than the one we’re currently on? Let’s migrate there. What supplies are we missing to
build a house? Wood. Why don’t we have wood? Because we haven’t cut down any trees Why don’t we cut some
trees? Well, it’s nighttime so the ‘hostile mobs’ (monsters) are out and we’re not sufficiently equipped with the right
armor, weapons & tools. What can we do about that? We can quickly mine dirt blocks to build a house, risk felling
some trees in the dark by ourselves or if we group together with other players, we can divide our problem into tasks.
Which tasks? Well, some of us can protect against the monsters, some can collect the wood, some collect food so
we don’t die of starvation, and the rest can build the houses once the wood is safely collected. However, the more
people we have, the more food we’ll need to collect so what do we do about that? Well it’s only possible to die of
hunger in ‘hard mode’. Should we switch to ‘normal mode’? You’ll still lose most of your health from starvation
2015 EMC Proven Professional Knowledge Sharing 44
though. ‘Easy mode’ then? You’ll still lose half of your health from starvation and if there are too many monsters,
some of the food collectors might need to join the protectors. Really, so ‘peaceful mode’ then? In that mode you
don’t ever hunger and there are no monsters.”
With the most important of questions being “What do we feel like creating today and who’s
available online now to do it together?”
They communicate via desktop headsets, server chat-rooms, and mobile phones as they
“playcreate” with each other. They write “mods” to modify the rules and reality of the game
together. They record their own and watch others’ YouTube video tutorials to teach and learn of
new game experiences. They create out of desire, not out of need!
As shown in Figure 25, they are a real-time community of collaborative creatives. As young
AppDevs, they extend the importance of the
relationships to a higher level than just the data
points. The relationships that matter most are
between the human points – in both friendships
and score.
Everyone’s affected
Regardless of generation, every day in the life of an
AppDev comes with a renewed realization that each of our actions and non-actions will have an
effect on those involved and uninvolved alike – everyone’s affected by our choices. The
relationships between data and human points are the observational tools that enable us to
sharpen the scrutiny of the choices we make. Whether you feel you strive insecurely in a world
of scarcity or thrive excitedly in a world of abundance, we’re all connected in either case and in
many ways. A Communicator AppDev chooses wisely yet adventurously but always asks
themselves and others first how their idea might create and destroy value before pursuing it.
The value of Mentorship
Regardless of your trade or discipline, communicating ideas, asking questions, and benefiting
from experience-driven answers is greatly enhanced with a mentor. Communicator AppDevs
understand the value of standing on the shoulders of giants and the best purposefully seek out
Figure 25: MineCraft Masters
2015 EMC Proven Professional Knowledge Sharing 45
these giants. I, among others who have had the opportunity to work alongside these wise,
compassionate, and gentle giant mentors, have had our careers enriched by the experience.
Case in point - Personal experience:
In my case, when I first met Shawn, I was already a practitioner of mentorship but only in
one direction – top down. I hadn’t yet learned the more valuable bi-directional approach
to that concept with which he would soon humbly enable me. Only a few years my
senior, he had developed quite an impressive number of applications that had enabled
the lives of many community college students and had caught the eyes of the Gates
Foundation. He agreed to be my “go to” resource regarding any questions I had while
developing applications for the college’s distance learning department. As busy and
high-profiled as he seemed to be, he always chose to listen and seek to understand my
current points of reference before speaking and biasing me with any of his. He attached
no stigma to asking “stupid” questions. In fact, he had quite the propensity for empathy
and often recognized, by observing my body language, when I felt my questions to be
so. He would take these moments as an opportunity to relate previous similar
experiences, to encourage me to ideate as off-the-wall as I could and to embrace failure
as a teaching tool. Sometimes he even cheer-led me to fail faster so that I could pick up
great understanding of many relationships between the data and human points along the
way!
Failure is such a great humanizer that inevitably, if you find a mentor AppDev as humble as
Shawn was to me, humorous conversations and a relaxed relatable learning experience will
result for both mentor and mentee. Whether we were developing a mobile app, debugging code,
writing technical docs, writing music, or delivering presentations at national conferences
together, his attitude throughout these projects and accompanied light-hearted conversations
always embodied the age-old saying that “knowledge is power” – but with an interesting twist.
Instead of lording knowledge over me (as my previous experiences had taught me to expect),
he sought to enable both of us with it by equally sharing in the failures, successes, and learning
we came across. So there the lines seem to blur. If an AppDev seeks to enable both mentor and
mentee, which one is which? A wise answer might be that they take turns at both roles while
forming a co-mentoring relationship. Co-mentorship not only enables us to combine experiences
from which to derive new ones, but in the process of “teaching” the other, you also gain a better
2015 EMC Proven Professional Knowledge Sharing 46
understanding of what you think you already know by attempting to communicate these ideas
effectively to those processing them for the first time. When you teach, you also learn. I know no
better feeling than when giving and receiving occur simultaneously in each transaction and have
modeled my communication style around this co-mentorship paradigm when working with
colleagues, friends, family, and definitely my young AppDev Net Gen kids who teach me
something new every day.
In his closing address to an online Songwriting class at Coursera.org, Pat
Pattison, a Professor at Berkley College of Music, where he teaches
Lyric Writing and Poetry, summarized this mentorship dichotomy as
follows: “Teaching stimulates more learning for me than anything else. When I try to
articulate something clearly enough for someone else to understand it, it takes on a whole new look. One of my
favorite bands in the 60’s was Procol Harum. Here’s a snippet of a lyric from their third album, Shine on Brightly,
that’s been with me for all these decades:
The lesson lies in learning
And by teaching I’ll be taught
For there’s nothing hidden anywhere
It’s all there to be sought”
Brainstorm, Divide, and Conquer
Whether engaging in voluminous human observations and questions; identifying the
relationships between data points, human points, and the effects our ideas and
choices have on both; or participating in a co-mentorship style of learning, nth
degree communication serves AppDevs well – to a point. When the threshold
of “information overload” is reached however, said information ceases to be
helpful. The TMI (Too Much Information) world we live in, thanks in part to the constant and
disruptive innovations of the information age, is a cold-hard truth AppDevs need to cope with
every single day of their lives. We attempt now to identify the sources of this barrage of data in
which AppDevs choose to brainstorm, divide, conquer and, sometimes … ignore.
2015 EMC Proven Professional Knowledge Sharing 47
Stakeholders, Target Audiences, and Niche
When you develop an application, you need to realize that it’s not yours. Whether an enterprise
developer works on a global team or an indie developer works solo out of their garage,
AppDevs are usually creating something for someone else. They may enjoy creating it, but each
still has to answer to the application’s (1) stakeholders, (2) target audiences, and (3) niche. Any
seasoned AppDev knows that these three are the true owners of the app and successfully
navigating the data-barrage from each is often much trickier than the actual coding. Let’s
identify each;
1. Stakeholders own the application due to the nature of the relationship they have with
you as an AppDev - they are paying you to create something for them or for their target
audience. You as an AppDev report directly to them so any output emanating from this
source must become your input while developing the application.
2. Target audiences own the application due to the relationship they have with your app –
they are using it. They might be indirectly paying you to use the app by paying your
stakeholders who are themselves directly paying you – ex: online science lab
applications for a community college.
They might be directly paying you to use the app when they themselves are the
stakeholders – ex: branding applications for business websites, mobile apps, and email
campaigns. They might be simultaneously paying you both indirectly and directly to use
the app when they pay an “app store” prior to download. As a result, you are getting an
indirect cut from their direct payment to the “app store”. The permutations of this target
audience relationship are many but suffice it to say that once you release your
application into the wild, you as an AppDev report to your target audiences on a
multitude of levels – even more levels when your application has multiple target
audiences (more on that later). Output can emanate from this source in
the form of: app store comments; faculty/student
observations, suggestions and complaints; supporting blogs. In
addition, YouTube video tutorials, and other social accounts
and online communities you might find
yourself needing to moderate; feedback from
conferences and other public speaking
2015 EMC Proven Professional Knowledge Sharing 48
engagements; decisions from steering committees; bug-fixes and patches provided by
the community; analytics collected from client devices in an attempt to provide cross-
platform experiences; integrations with other 3rd party applications. All of these become
your input.
3. Niche owns the application due to the service relationship it originally intended, for you
as an AppDev, to cultivate between your application and target audience. Huh? Yes, it
was difficult to precisely describe that concept in just a few words so let’s try a few more.
Wikipedia defines Niche market as “a focused, targetable portion (subset) of a market
sector”. We’ll borrow some of that definition and say that an AppDev’s conceptual phase
application (when zero lines of code have been written) has “a focused, targetable
portion” of functionality intended to serve “a focused, targetable portion” of humanity.
This, we call, the application’s niche. It’s up to the AppDevs (team or solo) to identify,
clarify, maintain, and protect the application’s niche as soon as the first line of code gets
written and throughout the development life of said application. Doing so preserves the
application’s original service intentions and prevents these from becoming diluted by
later “add-on intentions” that can eventually and silently saturate or bloat the application
into a hammer solution for a non-nail problem. Earlier, we stated that the applications we
create as AppDevs are not ours. This is true even when we own the application’s niche –
we still don’t own the application. However, even when we own the niche as AppDevs,
we report directly to it. In the case of the application’s niche, the source creating the
output is the very same that collects it as input – our conscience.
Diverging Convergence
Stakeholders, target audiences, and niche create volumes of data for AppDevs to swim in. From
past experience, I have found that the best AppDevs are very good data swimmers because of
the creative knack they have for divergent
thinking as shown in Figure 26.
Again, to reference Sir Ken Robinson’s TED
Talk, “How Schools Kill Creativity”, he defines
divergent thinking as “an essential capacity for
creativity” that enables us to see many
possible and non-linear ways of interpreting the Figure 26: Divergent Thinking
2015 EMC Proven Professional Knowledge Sharing 49
Figure 27: Example of Analysis Paralysis
questions to be asked as well as the many possible and non-linear answers to these very
questions. AppDevs equip themselves with this outlook quite well during the ideation or
brainstorming process.
The ELSE is the easier half of
the IF statement presented in
Figure 27 and a seasoned AppDev
needs to be wary of the “analysis
paralysis”, that can result when
combining their divergent thinking with the infinite scenarios and data sources available to them.
Eventually they need to take the infinite outcomes and converge on a specific set. It can be
argued that the Agile approach described in the Design Principles section starting on page 22,
provides AppDevs with a degree of divergent thinking latitude since its process of discrete and
unitary increments of functionality mandate both divergent and convergent thinking per iteration
of development.
Requirements vs Desirements
Divergent thinking creates a wealth of data. When you combine divergent creatives,
stakeholders, target audiences, and niche in the same room, this wealth of data can often lead
to poor choices when AppDevs fail to demand a clear division between requirements and
desirements early on. Regardless of SDLC preference, AppDevs need be good stewards of
each. Requirements need stewardship because these can provide a focused way of uncovering
the truth of the needs the application is meant to fulfill, as well as the descending priorities of
each need (due to available resources, stakeholder buy-in, etc.). Once the uncovered needs
begin scoring a low-enough priority level, these should be consistently and visibly stewarded as
nice-to-have or “desirements” functionality. Desirements provide a safe-guard to forgetful
humans, decision makers who aren’t available during key meetings and late unvetted ideas.
They are also important because everyone likes to feel that their ideas are valuable. If an idea
doesn’t make the requirements list, a desirements list confirms this value without destroying the
value of the application to be developed from the requirements list. If a desirements list sounds
like lip service to any involved parties, note that good AppDevs understand this list to be the
birthplace of future requirements lists during subsequent iterations of the application’s
development.
2015 EMC Proven Professional Knowledge Sharing 50
Under-Promise vs Over-Deliver
A connective tissue to the practice of “requirements vs desirements” is “under-promise vs over-
deliver”. As AppDevs mature, they realize the importance of keeping the implementation details
of the requirements lists to the bare-bones of what’s possible given the resources currently
available to them. As excitable as younger AppDevs might get about the infinite possibilities of
their imaginations, requirements should never be embellished past these finite resources or un-
curated expectations and eventually failure will result from these pie-in-the-sky endeavors.
Should more resources become available (time, headcount, money, technology) after
completing a current list of requirements and you feel like adding muscles to your under-
promised yet completed skeleton and connective tissue, great – over-deliver higher value
anatomy only then! Limit your data-barrage processing to the praise you’ll receive after
unexpectedly wowing your stakeholders!
Gates, Hurdles and Constraints
AppDevs can’t always expect to deal with the data-barrage by brainstorming or dividing their
way around it – sometimes they just need to conquer their way through it.
AppDevs need to traverse many gates and gate keepers on their way to creating that “killer
app”. An “app store” gate might protect its interests, making sure that yours align with theirs
before they ever let you in. SDLC gates might make you forever wait in between testing,
developing, Q&A, and production cycles. Departmental silos sometimes gate the speed of your
development forcing verification by storage, network, compute, security, and legal gatekeepers.
If they’re developing applications for an employer, AppDevs have to abide by all the constraints
imposed by the employer’s existing processes and their relative stakeholders’ needs. If self-
employed, AppDevs have to abide by all their self-imposed (or sometimes self-implode)
constraints: money, energy, health, dreams. They also need the ability to actually maintain
those resources long enough to complete that “killer app”. These constraints often translate into
higher development cost and context switching. Both are costly barriers to developing an
application: Time = Money. However, while financial cost might be the more obvious hurdle to
overcome I, as an AppDev myself, tend to view context switching as the more costly
impediment to developing an application of the two. Case in point: if a pre-existing process
mandates that every time a new feature is added to an app it must be tested, the creative task
of developing is interrupted. The longer the feature flow is interrupted with these context
switches, the more time is lost each time AppDevs need to regroup their thoughts and switch
2015 EMC Proven Professional Knowledge Sharing 51
back to refocus on the original inspiration responsible for generating that last feature. When
AppDevs are prevented from keeping the overall bigger picture in mind long enough to write
systemically coherent code, poorly written applications often result. However, there is a silver
lining when it comes to the cost of developing an app. Cloud computing is relieving some of
these constraints by automating many of the context-switching burdens that divide AppDevs
from the flow of their creations. When manual, mundane, and error-prone tasks can be
automated, more creative autonomy can be afforded the AppDev!
Think “inside out” of the Box!
Whether AppDevs are a divergently convergent creative species to begin with, I propose that all
the gates, hurdles, and constraints they must face are the salt that further seasons the creations
they dish out to humanity! When being placed inside a box they’re simultaneously being asked
to think outside of, AppDevs have to further sharpen their creativity in order to successfully
ideate amidst the imposed limitations and obstacles. Along with thinking “outside the box”,
they’re also often asked to “multitask”, neither of which prescribed bad medicines should ever
be blindly swallowed. Thinking outside the box becomes great medicine only after an AppDev
has already spent a decent amount of observational time inside it. Once you understand the
constraints involved, by all means find a solution that creatively enables you to operate outside
of their limitations without undermining existing processes that depend on them!
In Figure 28, I recently tweeted the following
quote from a great observer of human-
imposed boxes, Pat Pattison. While we
haven’t covered “The Artisan Developer” just
yet, I feel that Pat’s sentiment humorously
identifies with my development experiences
at times when fellow AppDevs and myself
have been asked to think in this way. If it were up to me, I would prescribe a variant to these
box-thinking pills and suggest that you think “inside out” of the box. There’s a time and place for
both. AppDevs need to consider the appropriate context for each.
Multitasking becomes great medicine only after an AppDev has already spent a decent amount
of time experiencing the power of “unitasking”! It’s great to be able to multitask when you have
no other choice, but nothing beats actually completing a single task extremely well before
Figure 28: Inside vs. Outside the Box
2015 EMC Proven Professional Knowledge Sharing 52
Figure 29: Myth of
Multitasking
moving on to the next! It may not always be possible nor desirable for AppDevs to inform their
boss of their unitasking choices but when the end results speak for themselves, well … Many
studies have already proven multitasking to actually decrease productivity but Dave Crenshaw,
author of “The Myth of Multitasking” takes it one interesting step further
by referring to it as “switchtasking” instead. I suggest any would-be
AppDev take Dave’s simple 5 minute test by clicking on the YouTube
video in Figure 29 to understand the dangerous noise that multitasking
can be to their creations and save themselves many wasted years of
unnecessary frustration.
Dangerous Waters
Sometimes constraints can be considered just a nuisance, and the waves of data these create,
just unnecessary noise. In these cases AppDevs can, and sometimes should, learn to ignore
them if they are to lead productive lives. However, sometimes nuisance constraints and noisy
data can rise to the level of actual danger. Before the waves get high enough to cause damage,
AppDevs best move away from the beach’s narrow view of the shore and investigate the source
from the mainland where it’s easier to spot the incoming storm. The sources of damage-
producing data are numerous. We identify a short list of heavy hitters below of which every
AppDev should be aware:
1. Repetitive Strain Injury(RSI)
The best solutions to this ever-present threat involve a healthy combination of ergonomics
and exercise. To achieve a sustainably healthy and productive development environment,
all physically suboptimal scenarios produced by said environment need to be proactively
addressed as they occur.
2. Distractions vs Flow
Being bombarded by distractions at consistently high-peak levels removes an AppDev’s
ability to enter a state of flow, or complete immersion, an essential ingredient for achieving
creative work of any value.
Psygrammer.com summarizes below:
2015 EMC Proven Professional Knowledge Sharing 53
“Programming in the zone — or ‘The Flow’ as it is known in psychology — deserves better understanding. Why? Because
many developers share this experience and rage against environments that don’t support their desire to work in the zone. […]”
“[…] ’achieving a flow state is positively correlated with optimal performance in the fields of artistic and scientific creativity’ […]
‘flow is positively correlated with a higher subsequent motivation to perform and to perform well’ “
“What are the distractions? Open plan offices, interruptions for meetings, talkative colleagues, slow equipment, IM, Twitter,
iTunes, email and much more. What are some other inhibitors? Working on tasks outside your competence; lack of
confidence in your own ability to tackle a task; lack of a clear direction for work.”
Mihaly Csikszentmihalyi’s TED talk calls flow the secret
to productive happiness.
3. Competing Industry Forces
Development frameworks and technology stacks are constantly in a state of flux. It’s
important for AppDevs to keep up with this development flux to a degree. However, when
they catch themselves reinventing the wheel and driving similar solutions to previously
solved problems, AppDevs need to take a step back from the beach and decide who the
“latest language” and tool set is benefiting most. Are either external 3rd party vendor
interests or internal “not invented here” (NIH) syndrome at play? Can the AppDev achieve
the same result via reuse of previous solutions or tools? Remember, tomorrow will always
bring more change.
4. Losing Relevance
The IT industry often preoccupies itself with this fear. Although the concept of “losing
relevance” is not necessarily a myth in need of debunking, the degree to which the industry
uses this fear to influence an AppDev’s decisions often calls for a healthy dose of skepticism
and discernment. Two helpful guidelines to navigating this barrage follow:
Stay relevant by focusing on the relationships between the data and human points.
2015 EMC Proven Professional Knowledge Sharing 54
The only time AppDevs need to worry is when their focus is too heavily placed on the
data points themselves (technologies). With enough time and disruptive innovation,
these do become obsolete and eventually – irrelevant.
The Big Picture
So far, we’ve considered volumes of data from many sources. These included but are not
limited to data from the owners of the application (Stakeholders, Target Audiences, and Niche),
data from diverging convergent brainstorm sessions and data categorized under the label
“dangerous waters” AppDevs need to avoid sinking in. Having considered each of these,
AppDevs then need to compare the top-down vs bottom-up views of this data to reconcile the
two directions into a functional application. An architectural mindset aids in balancing this
ledger. An architectural mindset considers every perspective of a plan: from the solid
foundation, to the structure supported by it, to the variety of tenants and to the diversity of their
current and future needs. AppDevs factor all data and constraints previously outlined into the
conceptual designs of the application and its architecture. Application architecture is often
divided into 3 analogous tiers: back-end, middleware (middle-end) and front-end. In the front-
end, AppDevs focus on items affecting the application’s presentation layer: user interface (UI),
client-side programming, end-user experience, different browsers, different client devices. In
the middle-end, AppDevs focus on items affecting the application’s plumbing layer: server-side
programming, business logic, requirements and desirements from stakeholders, target audience
& niche. In the back-end, AppDevs focus on items affecting the application’s persistence layer:
databases and other data stores. Simultaneously operating from 3 architectural tiers, AppDevs
need to also consider the team’s current skill sets, currently leveraged technologies, future
plans to extend functionality, legacy compatibility and moving target dates. It can quickly
become a very complicated process, especially when AppDevs work alongside those choosing
to specialize in only 1 of the 3 tiers: therefore the notion of back-end developers, middle-end
developers and front-end developers. Some see only the foundation, some see only the
structure and some see only the tenants or target audience. AppDevs need to see all of them.
Some see the architecture from the bottom-up, viewing the foundation as most important and
every layer above less so. Some see the architecture from the top-down, viewing the tenants
as most important and every layer below existing solely to support this top most layer.
Successful AppDevs employ a holistic approach and tackle the architecture from both these
angles to tease out all the details in between.
2015 EMC Proven Professional Knowledge Sharing 55
“Nothing for All” vs “Something for Some”
Employing this architectural mindset serves AppDevs well but even architecture needs to be
used in moderation. When the application’s service expectations become bloated and
AppDevs find themselves over-architecting the app to fit a mold that is useful to too many
people, they need to apply the breaks. Revisiting the originally intended service requirements
with the stakeholders becomes a healthy discussion to have at this point. Stakeholders might
have the ultimate say in the app’s functionality, but they would be quick to agree that an app
achieving “something for some” people is much preferred over an app achieving “nothing for all”
people. AppDevs need to be ever vigilant of these 2 outcomes, cautiously steering the entire
team towards the first. When asked to make or add “just one simple little update/feature” that
seems out of scope, AppDevs need to discern whether these changes take into consideration
the application’s existing architecture, created from initial weighing and balancing of all the
original sets of interdependent requirements. This is not a mere question of a software
development life cycle (SDLC) preference. AppDev proponents of either Waterfall or Agile
(outlined in Design Principles starting on page 22) methodolgies, are subject to the same
disposable perspectives we share as a society on many products – including software. The
“ease” in which software seems to be modified runs in parallel with the constant risk of “easily”
creating bad software. Identifying niche needs and limiting the application to solving just these
while purposefully turning a blind eye to all others is a challenging but important practice for
preventing these “nothing for all” solutions.
Dev On - The Artisan Developer
As a Communicator Developer, we stated the importance of AppDevs using their eyes/ears
more than their mouths/fingers thereby throttling their input to a higher rate than their output.
This helped them humbly learn where value was missing before attempting to add it. A Day in
the Life of an Application Developer continues now with the flipside to that. We observe the
Artisan Developer in their natural environment, where after taking in all the previous inputs and
simmering in them, inspiration now throttles their output much higher.
Meaning
Everyone wants to feel like his or her life has meaning, a purpose. This is no less true of the
AppDev and especially true of the artisan AppDev who chooses to absorb life’s every stimulus
through an amalgam of their body’s five senses and multiple angles of perception – their own
2015 EMC Proven Professional Knowledge Sharing 56
and their world’s combined. After enough stimulation however, these folks need to do something
with all that they’ve taken in, sometimes exploding like a star. Newborn stars explode into
existence while old ones explode out of existence so we leave the interpretation of the star
comparison up to the reader.
Like crowd surfing rock stars, crowd sourcing AppDevs often want to “touch” the lives of many in
meaningful ways: physically, emotionally, spiritually. Towards achieving those ends, rock stars
might say “We Make Beautiful Music” while AppDevs might say “We Make Beautiful Apps”, but
in either case, they both make beautiful human experiences.
Infinite to MVP: Replicating Ground Zero
An AppDev gets an initial creative spark. Their idea spans in infinite directions – it has a central
point that’s focused, very laser sharp and focused, but the possibilities are limitless, endless, as
infinite as the analog waveforms of the infinite brain conceiving the idea. Something new is
born. Maybe something old is made better. Now, how do they get that idea – that infinitely
possible idea – down to a discrete, quantifiable set of zero’s and ones for a computer, for a
mobile phone, for a tablet, for any device to replicate?
AppDevs need to sample their infinite idea into a
much smaller subset. How do they do that?
It’s an art! They can’t replicate the entire idea,
so, they start with a Minimum Viable
Product (MVP). They start, with
ground zero. They try to replicate,
just ground zero soon!
What is their app? What do they want to do? What do they want to change about the world?
What do they want to make better about the world? What do they want to introduce to the
world? That is their app – the MVP, just a window into it! They compress that app from an
infinite number of possibilities down to a constrained number of realities. In time, as constraints
are thoughtfully overcome by the AppDev, the minimum viable becomes multi-viable and the
app’s feature-rich original intentions – explode into being.
2015 EMC Proven Professional Knowledge Sharing 57
ArtDev Evolution?
Over the years, I’ve personally run in enough technology circles to recognize the uncanny
relationship between technology and the arts. It seems more than just a coincidence that these
two intertwine. While recalling my experiences in writing
educational software alongside folks who were both
AppDevs as well as musicians, I submitted the following
to a Google “Open Web” event (Figure 30). proposing:
1. Technology and Arts share a relationship that should
never be separated when teaching our youth.
2. An open web can aid in that cause.
Whether meeting these AppDev musicians at coffee
shops or in bars, over time our conversations would
gravitate toward evolutionary realizations of the roles we
had played and progressed from as AppDevs in this
world. I split our discovered evolutionary path into the
following three categories along with their potentially
controversial definitions, depending on your starting
frame of reference:
1. Software Developer (SoftDev) - develop what’s asked for
2. Application Developer (AppDev) - question what’s developed
3. Artisan Developer (ArtDev) - create what’s not asked for but sorely needed
The general tone of these AppDev Musician conversations indicated that many an AppDev had
identified themselves in the similar chronological order of SoftDev AppDev ArtDev while
progressing through their careers. As they experienced more of the pain and joy that is the
human condition, many had become interested not necessarily in treating it, as you might a
medical condition, but in relating to and elevating it – in a profound way.
Figure 30: Google Open Web Submission
2015 EMC Proven Professional Knowledge Sharing 58
Musical Crossover
The ArtDevs referred to above might stem from an AppDev Musician perspective when
considering their software-to-artware evolution, but our richly growing multimedia- and software-
defined world has the potential to extend this transformation equally well to any AppDev with an
artisan side: AppDev Painters, AppDev Sculptors, AppDev Actors. We’ll continue our
exploration from the AppDev Musician point of view and the affinity of patterns both disciplines
seem to share. A Wikipedia excerpt states this relationship between music and math
“mathematics is ‘the basis of sound’ and sound itself ‘in its musical aspects... exhibits a
remarkable array of number properties’, simply because nature itself ‘is amazingly
mathematical’.” Whether or not they love math, both the AppDev and Musician has a propensity
for being good at recognizing patterns in nature, leveraging these in their creations, and
reflecting them back to the world in a magnified way. For the AppDev, “pattern matching” is
extremely valuable. Whether identifying the cause of failure in error logs or recognizing
emerging trends in technology, better software results when you’re able to “see in numbers” and
appreciate the repeating relationships between data and human points. (And you thought we
were done talking about these?) “Regular expressions”, a syntactical construct available in most
modern programming languages, augments their own natural ability to observe patterns.
Musicians indulge in “pattern matching” every time they play a certain piece of music. Time,
rhythm, meter, and frequency are some of the musical constructs that augment their own
natural ability to observe patterns … in sound. Audience response (dancing, singing, smiling,
frowning, frequency of song requests, genre, digital downloads per zip-code, online fan
communities, t-shirt sales, etc.) are some of the social constructs that augment their own natural
ability to observe patterns … in humanity.
Creative Crowdsourced Explosions
For both AppDev and Musician, being able to identify patterns of human need means they can
begin the process of seeking to solve these. When their natural
ability to “pattern match” is further augmented by software,
beautiful explosions of creation can result, fulfilling the human
need. For Tim Westergren, co-founder of Pandora Radio, the long
road that was Pandora is one such beautiful explosion.
Interestingly, the story begins on the other end of the spectrum
2015 EMC Proven Professional Knowledge Sharing 59
with Tim as a musician prior to diving into the AppDev world. In a 2013 talk at Chicago Ideas
Week, he tells Pandora’s story. While struggling with his own band, Tim noticed many other
extremely talented musicians unable to earn a living and eventually giving up to look for “a job”.
His immersion with the plight of the working musician helped him recognize the overwhelming
pattern of both artists who needed decent exposure and fans who needed a way to find new
music without artificial popularity suggestions. “ … since Pandora's approach to serving up
tunes doesn't use popularity as a criterion, every composition in the catalogue, whether it's
recorded by an unsigned band or by a major-label artist, has an equal chance of getting played
and finding an audience.” The long road to solving this need didn’t begin with Pandora however.
Before Pandora existed, Tim had become a film composer and had developed a manual
process of identifying a film director’s musical tastes as a guide to deciding on the type of music
to eventually write for the film. His idea to codify this process into a product leveraging
technology to build a discovery engine eventually became known as the Music Genome Project.
“The Music Genome Project technology was developed by Glaser with musical input from
Westergren. The idea was to create a separate, individualized radio station for each user having
just the ‘good’ music on it, with none of the ‘junk’ that other users like. In order to achieve that
goal, they had to bring different styles of music
together into a predictable pattern for analysis.”
The Music Genome Project and its complex
mathematical algorithms uncover the
relationships between different music by
comparing over 450 musical characteristics or
“genes” and by crowd-sourcing individual tastes as the core of Pandora, building new
relationships between artisan and fan every day.
Priceless Art vs Cheap Apps
Not all great ideas explode into Pandora-sized apps. AppDevs need to fight through many
gates, hurdles, and constraints on their way to tangibly actualizing the intangible ideas trapped
in their heads. This is especially true for ArtDevs whose technological idea is artisan in nature.
Even when the idea reflects some portion of humanity back to itself in an attempt to solve their
needs, by virtue of being an ArtDev, they might be going about the solution in an unconventional
2015 EMC Proven Professional Knowledge Sharing 60
manner and can expect push-back. Tim Westergren’s road is a long one for a reason and still
is. In the disposable society we’ve adapted to living in, it’s become unconventional to create a
product that cares more about the human condition than about making money from it. Would
you ever ask a painter to update a classic Norman Rockwell to a more edgy, superhuman Stan
Lee? No! Would you ever ask a musician to update a classic Brown-Eyed Girl to a more
alternative, hip hop Black Eyed Peas? No! At least, not unless it’s a dance mix Would you
ever ask an AppDev to redo their finished LMS (learning management system) to behave more
like a MOOC (massive open online course)? Of course you would! But, why is that? Are
developers’ applications dispensable commodity products not worthy of being considered as
one-of-a-kind works of art in their own right? Does the fact that they are easily modifiable and
replicable in comparison to “real art” cause this mentality? What if we thought of applications as
organic art that grows and morphs over time? Would we then value each iteration as a unique
masterpiece or would we keep nonchalantly asking developers to make/add “just one simple
little update/feature” without respecting what was accomplished before? Without first
considering all the interdependencies that may have been injected by all the varying
stakeholders’ “requirements” and “desirements”, we could end up with “nothing for all” solutions.
However, if AppDevs and their artisan sides don’t adapt to the flux this climate brings, they can
find themselves and their artsy ideas quickly becoming irrelevant no matter how good they
might be. Do they need to learn how to fail and morph their creations faster and cheaper by
leveraging dynamic, software-defined cloud development environments like a Platform-as-a-
Service (PaaS)? Will these environments expedite innovation by removing the wait time
between brush and key strokes, enabling them to keep their thoughts and inspiration in constant
united flow? AppDevs with a “Change the World” mentality who feel that music inspires, art
inspires, and code inspires, will do best to remember that performers perspire and don’t mind
sweat equity in a world of constant change. If knowledge is power, power that helps AppDevs
adapt to this change, then creativity is the humble curiosity that helps AppDevs create the
change itself. There’s an abundance of each begging to be thoughtfully combined!
2015 EMC Proven Professional Knowledge Sharing 61
Bringing it all together
We have seen how AppDevs are multifaceted individuals that constantly juggle social,
technological, communication and creative demands. So are they creating Priceless Art or
Cheap Apps? Good AppDevs are experientially focused on how the world will benefit from their
contributions. Conscientious AppDevs are concerned with crafting technological solutions to
every day problems and always have in the forefront a clear understanding of the need these
apps are intended to serve. In other words, they are uniquely "wired" to first identify
opportunities to create value where value is missing and then, develop cutting edge solutions to
support those needs. It’s within the realm of the co-existance between the right side and the left
side of the brain that AppDevs can do what they do best: create effective and functional apps
that enhance the human experience. It is the inherent value of these apps that make them
indispensable to the consumer and in the process, prove to be financially profitable to the
stakeholders. True, this is a fast moving industry where new discoveries or developments often
render “just finished” apps obsolete or replaceable. However, an effective AppDev does not
equate the need to develop need-informed apps expeditiously with cranking out un-functional
apps at breakneck speed. As Marc Andreessen said: "Software is eating the world". At the end
of the day, however, software is supposed to make life easier whether created for the individual
user or for multibillion-dollar corporations. Effective Application Developers are crucial to
making this reality happen.
2015 EMC Proven Professional Knowledge Sharing 62
Music Video Grand Finale
Once again as per the AppDev
way, let us combine the left and
right sides of the brain for maximum
effect as we now see what a “Day
in the Life of an Application
Developer” really looks like through
a music video grand finale! Click
on the image or caption referenced
by Figure 31: A Day in the Life of
an Application Developer, to launch
the video. You can also click on this
link -
http://tiny.cc/ADayInTheLifeOfAnAppDev
Figure 31: A Day in the Life of an Application Developer
Dev On!
2015 EMC Proven Professional Knowledge Sharing 63
Authors’ Biographies
Rene Vogt-Lowell is a Senior Education Technology Consultant at EMC in the New Product
Readiness Group based in Franklin MA and has had the chance to serve humanity in many
ways through 19+ years of multi-faceted IT experiences. A strong believer in mentorship, Rene
strives to balance sharing against receiving of knowledge and perspectives with and from others
through productive co-mentoring relationships. As a senior application developer, Rene lead the
development and mentorship of junior developers on over 20 online science labs, simulations &
mobile learning games. He has presented at many national e-Learning conferences
representing Sinclair Community College where great acclaim and repeated awards were
received for their pioneering online science lab program & their first mobile science lab. As an
independent software consultant, Rene has applied both Adobe and open source solutions in
the education, health, entertainment, data warehousing, medical & automation industries. As a
stage performer, musician, college instructor and father of two, Rene has enjoyed throttling and
repackaging his message delivery against many diverse audiences and backgrounds.
Certifications include EMC Proven Cloud Infrastructure and Services Associate, CompTIA
Linux+ Certified Professional & hopefully soon Coursera Modern Musician so he can indulge in
the creation of Interactive Music Videos
Paul Brant is a Senior Education Technology Consultant at EMC in the New Product Readiness
Group based in Franklin MA. He has over 29 years’ experience in semiconductor design, board
level hardware and software design, as well as IT technical pre-sales solutions selling as well as
marketing, and educational development and delivery. He also holds a number of patents in the
data communication and semiconductor fields. Paul has a Bachelor (BSEE) and Master’s
Degree (MSEE) in Electrical Engineering from New York University (NYU), located in downtown
Manhattan as well as a Master’s in Business Administration (MBA), from Dowling College,
located in Suffolk County, Long Island, NY. In his spare time, he enjoys his family of five,
bicycling, and other various endurance sports. Certifications include EMC Proven Cloud
Architect Expert, Technology Architect, NAS Specialist, VMWare VCP5, Cisco CCDA, CompTIA
Security +.
2015 EMC Proven Professional Knowledge Sharing 64
Appendix A – References
i The game was created by Markus Alexej Persson (born 1 June 1979), so not a Net Gener but a Gen Y (1 gen up). http://en.wikipedia.org/wiki/Markus_Persson The enterprise took over “On September 15, 2014, Mojang AB and all of its assets (including Minecraft) were purchased by Microsoft for US$2.5 billion.” http://minecraft.gamepedia.com/Minecraft_Wiki
ii http://minecraft.gamepedia.com/Minecraft_Wiki https://github.com/walterhiggins/ScriptCraft/blob/master/docs/YoungPersonsGuideToProgrammingMinecraft.md
EMC believes the information in this publication is accurate as of its publication date. The
information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION
MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO
THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an
applicable software license.
