Detailed Notes
Welcome to another edition of Develpreneur. In this presentation, we are gonna be talking about software development. What goes into building software. Instead of this being just a run-of-the-mill discussion on SDLC, we will flip it on its head and take a different approach to software development. Previously, we have talked about things like software development SDLC, we've talked about software test life cycle, and we've given you the benchmark or textbook descriptions on these particular topics. Now let us talk about building software from an application perspective, building a new application from scratch.
What Goes Into Building Software..., It all begins with an idea.
Our journey will take us through software development or software development as a whole, from the perspective of a business. A lot of application ideas come from a round table discussion about an idea, need, or service that the business wants to solve with software.
Common Questions Asked During Round Table Discussion:
What is the problem we want to solve? How can we solve this problem with the software? Is this something we can automate? Where will this solution have the most impact? What type of application should we develop? Overview of What Goes Into Building Software
We will cover what is our problem? Start with the problem. Break down the problem. We're gonna design an application. We're going to talk about building a prototype application we're then going to briefly cover how to test our application and then go into deploying the application. And then finally at the end of the cycle, handing off the project to the customer and what are the next steps?
Transcript Text
[Music] so if we've done all of our due diligence we've gone through all the different phases we've worked out the kinks in our software what do we need to do to prepare for launch you know what do we need to do to push that button so that our software now goes live well you need to look at what it is required for us to actually go from our development environment to production is this going to be a cloud-based deployment you know are we going to push the button and release our software to aws or kubernetes or some other type of web or cloud-based solutions do we need to write deploy scripts do we need to script something out so that it's just a button we push the button and we have that continuous integration that continuous building and deploying of our applications say through like bitbucket is there any other type of coordination or integration that needs to be done before you can push the button by that i mean do we need to set up any user accounts so that once we go live people can log into this particular application do we need to do some type of alpha or beta run of the software kind of do a pre-launch or soft launch with the customers before we go live is there any type of data that needs to be added to the system before launch so at this point right before we go live as we're pursuing everything to the cloud or to our production environment is there any types of data scripts that we need to load to set up the application for use so these are some of the questions and things you need to look for here so when dealing with our classroom app so we potentially want to do something like a soft one so we would probably get a handful of users together have a couple people go in as instructors set them up set up some classes and then have a couple students mock students come in and actually try to use the application in a production environment so you do kind of a smoke testing in production if all that goes well then you do an official launch of your software and things are good so after you push that button we then do what we call a handoff or where do we go from here so the handoff is once the final project is delivered it meets you want to meet with the customer to present the final product this is where we discuss any issues that were essentially found at the end of the launch any particular issues with the software that was not caught through the entire process or possibly some issues that might be found from a user's perspective in ways in which the software is being used that was not initially anticipated or as far as the end user that they're using in a way that the software allows them to use it for but was not what it was intended for so do we have some bugs that we need to fix or functionality changes that need to be made so again here we also sit down and talk with how to deal with any additional features or issues that come up from the customer now if this is an internal product like this uh classroom application so at this point once we go live and once we have everything ready so where do we want to go from there so here we want to take that classroom application and we want to promote it we want to start building out our a boot camp idea or classroom idea and then we deploy it to our website and then we start marketing so the handoff could be to a customer or the handoff could essentially be to another department within the company for instance marketing so once the project is out there it's shipped now we need to kind of go through that marketing blitz for that campaign to get the product to market so that we actually get it out there we're you know presenting it to everyone and everyone's happy and we then start getting calls on the software so when you get ready for the handoff and we're live you also need to make sure that we deal with things like customer support so we may need to hire some additional resources based on the number of calls coming in now with customer support it could be two full one you might need a customer support page in order to support a larger base customer base if this is say like walmart or amazon where you have a large feature face to a lot of different people it could be as simple as you create a web portal or a some type of portal into your site where customers could come in and report uh feature requests or bug fits or bugs that they're encountering with the software so in that particular case you can then go through and triage uh you know on a weekly daily or quarterly basis what features you want to add or fix within your application if this is a piece of software you've written for a specific customer so you are essentially the development house and you are delivering the software to a organization or an individual then at that point once you hand it off you might get some additional feature requests or sign up on the product and you get paid so let me take a moment there and open this up for discussion i know it kind of went through this a little quickly but i wanted to save a lot of this for the q a so michael what is the most scary thing about starting a new project so one of the big things with project development or really any type of software development is do we have enough requirements to write the software so from a new project perspective there's always that unknown uh you might spend weeks days or years designing a particular application and the problem is depending upon the time it takes you to come up with the concept and the idea a couple things could happen one if you're very quick to market and you're like bleeding edge cutting edge the then you're you're basically going to have to figure out how to build the tools to get your product to market if you are building something that is using already existing technologies then you run um the gambit of okay cool i can build something i have all these tools and features out here i can use but what you potentially run into is okay now am i in a market where there is a lot of competition and is someone going to come steal my feature or am i going to build a feature that is going to be useful enough for someone to leave another product and come use mine and then you have the final risk where if you are taking so long to get to market you do so much time prepping and preparing uh your requirements to build your product did you miss your chance has someone else already beat you to the market and are you basically now building something that no one's gonna want i i know you talked about test test test in your presentation is like okay you okay you have this new product or new project you've worked on so when you say like you know what this project uh project has been tested or what percentage do you have to start to have to say like okay now i feel like i can sell this product let me say to the uh team or all the end users are like okay you can begin using this new project again that kind of depends on the application and it could also depend on the software shop so if you are a really good agile shop and this is a brand new application one of the things you could do early on in the agile process is come up with some quick requirements some quick design choices at the beginning prototype it out get something out there that may have one or two features now with the example the classroom application you're going to need to have at least some core functionality in place you can't kind of skip the whole classroom idea however if you want to introduce the classroom idea or maybe release like a presentation type software where you can have a instructor that can uh post or host a class and then you could have people log into the class so that could be one area where you could kind of get to market quickly uh without building out the whole classroom idea so you have this concept where okay i'm an instructor i can start up a presentation and then i can send links out to people and they can join into my uh my my lecture well that could be like quick to market phase one and then phase two okay now i start building that dashboard right or i build a uh like a workbook for the student so the instructor could post some assignments and the students could come work so you could do it in a phased approach so that's one of the things you got to be careful of when you're trying to build something new can you get something to market quickly enough with enough features that people are going to be interested and then as you slowly roll out the application are you going to keep their interest are you going to build the product that you want for the for the community one of the uh interesting ways if you do it this way is your initial idea your initial roadmap for your application might change based on the community that you're servicing so your initial thoughts for your end customer might not be the direction that the software ends up going however you do have to be careful with that because if you go down the path of following the community you might end up with a lot of scope creep so if you do listen to the community and you do build features based on the community response you need to be mindful that what you're building is still structured enough and tiered enough that you're doing things in a nice organized way that you can do that continuous development so that you don't end up in scope creep and basically uh one new feature doesn't take months to come out and say maybe it can take a couple weeks to come out oh cool man thanks michael oh no problem and that actually brought up a thought so one of the applications or games that i've played over the last few years that kind of really fits into this model is pokemon go so it it may sound weird but when the game first came out so they had promised all these features within this uh application that they were going to build for the pokemon community which was okay you can go catch your pokemon you're gonna be able to battle with your friends you can battle uh you know gym leaders you can battle team rocket well when the application came out day one for launch all you could do was basically go out and catch pokemon there was no other functionality in the game you couldn't even uh take pictures of your pokemon it was just simply here's google maps you're got a little skin you can walk around in the world you see pokemon pop up and then you try to catch them that was it so they over promised and under deliver however they made so much money on just that basic implementation that they delivered that they were able over the course of five years to build an application that met their initial target requirements and they built a community around their application that continues to grow today so that's one way to think about looking at your application now in uh take that same model and flip it they came out with another mobile application for harry potter uh wizards unite that completely flopped similar concept similar premise different genre they just could not get it to take off it just was basically they missed their mark the the application itself did not meet the expectations of the customer and because of that after a couple years that application is basically dead it has almost no development whatsoever and ensure the servers are still alive so those are kind of two examples one of how you can kind of quickly get to market unfortunately you over promise under deliver whereas another one you basically deliver something that was promised but ended up being something no one wanted good questions no but that's a good little follow-up is the which sort of goes into dave's question too is it's it is always the thing that sort of that balance of do we now we've talked about this a lot actually do we you know shoot for 100 or and wait longer or do we cut some corners and push this thing out yeah it goes back to you know lots of discussions we've had about code coverage and things like that but you know sometimes it's uh it's also it's not the amount of bugs it's just which bugs you know it's it's you're gonna have like those two games are examples where you have stuff where it's if you've got something that's pretty new or in an environment that's that's changing or challenging then you're going to have issues it's just sort of nature of the business but if you can solve a couple of the big problems and do those consistently and not take off your users then you've got a lot better chance for success it actually sort of buys you time then to come back and then get the smaller details exactly and that's kind of why i wanted to do this presentation to begin with because i wanted us to kind of revisit the whole software development life cycle that software test life cycle but from a higher level like take a step back and look at it from the not just the customer level but also look at it from the development the business model you know how are we actually looking at the whole development process very good all right so let's quickly recap so in today's presentation we walked through kind of the whole software development process from the business level we started out with talking about a problem in our particular case you know building a classroom or course application we talked about different ways of breaking down the problem looking at roles uh who's going to use the application what type of features you want in the application you know what type of frameworks and architectures do you want to need databases to different components so by breaking down the problem into smaller pieces it allows us to kind of pick and choose the different features that we want to roll out in our application quickly we then talked about designing the application kind of doing those storyboarding the wireframes of the application can i get the look and feel of the application before we actually go out and start building because if we do this first and we do it right when we get to the prototype phase actually writing the application putting it together we should hopefully reduce a lot of that overhead a lot of that scope creep and keep our costs low and get the product to market quickly we then also talked about testing and how that we need to go through and actually test the application not just from the user endpoint but test different things like integration use different types of testing tools making sure that things work so as long as the application works then we can move into the last the next two stages which is okay once the application is done once ready to deliver we deploy the application we push that red button we launch the application and then the software goes live and then once everything is out there once we start um fixing some of the bugs that are reported by the customer we talked about the handoff and next steps where we either deliver the software to the end user if we're our own customer or our own producer we could deploy our application to the app stores and then our customers could start downloading our apps and then what kind of you know what's the next step what type of features do we need to start including after this you know what type of additional support do we need if we start getting a lot of calls because there's potential problems or potential features requests you know do we need to start a marketing campaign to start promoting our application so these are the overall steps that we go through during the process of software development and as always i'd like to thank you all for your time and we appreciate you joining us and if you want to discuss any of our topics further not just software development but anything from our website you can send us questions comments or suggestions through any of these uh areas we are on email info development dot com you can reach us on our website we have a contact us page we're on twitter at developer nur we are on facebook at facebook.comdeveloperner and if you'd like to check out any of our other videos and podcasts you can check us out on developer.com our videos are also on vimeo.com developerner and you can find us on youtube if you go to youtube and in the youtube search type developer our goal is making every developer better have a wonderful day [Music] you
Transcript Segments
[Music]
so if we've done all of our due
diligence we've gone through all the
different phases we've worked out the
kinks in our software what do we need to
do to prepare for launch you know what
do we need to do to push that button so
that our software now goes live
well you need to look at
what it is required for us to actually
go from our development environment to
production is this going to be a
cloud-based deployment you know are we
going to push the button and release our
software to aws or
kubernetes or some other type of web or
cloud-based solutions
do we need to write deploy scripts do we
need to script something out so that
it's just a button we push the button
and we have that continuous integration
that continuous building and deploying
of our applications say through like
bitbucket
is there any other type of coordination
or integration that needs to be done
before you can push the button by that i
mean do we need to set up any user
accounts so that once we go live people
can log into this particular application
do we need to do some type of alpha or
beta run of the software kind of do a
pre-launch or soft launch with the
customers before we go live
is there any type of data that needs to
be added to the system before launch so
at this point right before we go live as
we're pursuing everything to the cloud
or to our production environment
is there any types of data scripts that
we need to load to set up the
application for use
so these are some of the questions and
things you need to look for here so when
dealing with our classroom app so we
potentially want to do something like a
soft one so we would probably get a
handful of users together
have a couple people go in as
instructors set them up set up some
classes and then have a couple students
mock students come in and actually try
to use the application in a production
environment so you do kind of a smoke
testing in production
if all that goes well then you do an
official launch of your software and
things are good
so after you push that button
we then do what we call a handoff or
where do we go from here
so the handoff is once the final project
is delivered
it meets you want to meet with the
customer to present the final product
this is where we discuss
any issues that were essentially found
at the end of the launch any particular
issues with the software that was not
caught through the entire process
or possibly some issues that might be
found from a user's perspective in ways
in which the software is being used that
was not initially anticipated or
as far as the end user that they're
using in a way that the software allows
them to use it for but was not what it
was intended for so do we have some bugs
that we need to fix or functionality
changes that need to be made
so again here we also sit down and talk
with how to deal with any
additional
features or issues that come up from the
customer
now if this is an internal product like
this uh classroom application so at this
point once we go live and once we have
everything ready so where do we want to
go from there so here we want to take
that classroom application and we want
to promote it we want to start building
out our a boot camp idea or classroom
idea and then we deploy it to our
website and then we start marketing so
the handoff could be to a customer or
the handoff could essentially be to
another department within the company
for instance marketing so once the
project is out there it's shipped now we
need to kind of go through that
marketing blitz for that campaign to get
the product to market so that we
actually get it out there we're you know
presenting it to everyone and everyone's
happy and
we then start getting calls on the
software so
when you get ready for the handoff and
we're live you also need to make sure
that we deal with things like customer
support so we may need to hire some
additional resources based on the number
of calls coming in now with customer
support it could be two full
one you might need a customer support
page in order to support a larger base
customer base if this is say like
walmart or amazon where you have a large
feature face to a lot of different
people
it could be as simple as you create a
web portal or a some type of portal into
your site where customers could come in
and report uh feature requests or bug
fits or bugs that they're encountering
with the software
so in that particular case you can then
go through and triage uh you know on a
weekly daily or quarterly basis what
features you want to add or fix within
your application
if this is
a
piece of software you've written for a
specific customer so you are essentially
the development house and you are
delivering the software to a
organization or an individual then at
that point
once you hand it off you might get some
additional feature requests or sign up
on the product and you get paid
so let me take a moment there and open
this up for discussion
i know it kind of went through this a
little quickly but i wanted to save a
lot of this for the q a
so michael what is the most scary thing
about
starting a new project
so one of the big things with project
development or really any type of
software development is
do we have enough requirements to write
the software
so
from a new project perspective
there's always that unknown
uh you might spend weeks days or years
designing a particular application and
the problem is depending upon the time
it takes you to come up with the concept
and the idea
a couple things could happen one if
you're very quick to market and you're
like bleeding edge cutting edge
the
then you're you're basically going to
have to figure out how to build the
tools to get your product to market
if you are building something that
is using already existing technologies
then you run
um the gambit of okay cool i can build
something i have all these tools and
features out here i can use but what you
potentially run into is okay now am i in
a market where there is a lot of
competition
and
is someone going to come steal my
feature or am i going to build a feature
that is going to be useful enough for
someone to leave another product and
come use mine
and then you have the
final risk where if you are taking so
long to get to market you do so much
time prepping and preparing
uh your requirements to build your
product
did you miss your chance has someone
else already beat you to the market and
are you basically now building something
that no one's gonna want
i i know you talked about test test test
in your presentation is like okay you
okay you have this new product or new
project you've worked on
so when you say like you know what this
project uh project has been tested
or what percentage do you have to start
to have to say like okay now i feel like
i can sell this product let me say to
the uh team or all the end users are
like okay you can begin using this
new project
again that kind of depends on the
application and it could also depend on
the software shop so if you are a really
good agile shop
and this is a brand new application one
of the things you could do early on in
the agile process
is
come up with some quick
requirements some quick design choices
at the beginning
prototype it out get something out there
that may have one or two features now
with the example the classroom
application
you're going to need to have at least
some core functionality in place you
can't kind of skip
the whole classroom idea
however if you want to introduce the
classroom idea or maybe release like a
presentation type software where you can
have a instructor that can
uh post or host a
class and then you could have people log
into the class so that could be one area
where you could kind of get to market
quickly
uh without building out the whole
classroom idea so you have this concept
where okay i'm an instructor i can start
up a presentation and then i can send
links out to people and they can join
into my uh my my lecture
well that could be like
quick to market phase one and then phase
two okay now i start building that
dashboard right or i build a
uh like a workbook for the student so
the instructor could post some
assignments and the students could come
work so you could do it in a phased
approach so that's one of the things you
got to be careful of
when you're trying to build something
new can you get something to market
quickly enough with enough features that
people are going to be interested
and then as you slowly roll out the
application
are you going to keep their interest are
you going to build the product that you
want for the for the community
one of the uh interesting ways if you do
it this way is
your initial idea your initial roadmap
for your application
might
change based on the community that
you're servicing so your initial
thoughts for your end customer might not
be the direction that the software ends
up going
however you do have to be careful with
that because if you go down
the path of following the community you
might end up with a lot of scope creep
so if you do
listen to the community and you do build
features based on the community response
you need to be mindful that what you're
building is still structured enough and
tiered enough that you're doing things
in a nice organized way that you can do
that continuous development so that you
don't end up in scope creep and
basically
uh
one new feature doesn't take months to
come out and say maybe it can take a
couple weeks to come out
oh cool man thanks michael
oh no problem and that actually brought
up a thought so one of the applications
or games that i've played over the last
few years that kind of really fits into
this model is pokemon go
so it it may sound weird but when the
game first came out so they had promised
all these features within this uh
application that they were going to
build for the pokemon community which
was okay you can go catch your pokemon
you're gonna be able to battle with your
friends you can battle uh you know gym
leaders you can battle team rocket well
when the application came out day one
for launch
all you could do was basically go out
and catch pokemon there was no other
functionality in the game you couldn't
even uh take pictures of your pokemon it
was just simply here's google maps
you're
got a little skin you can walk around in
the world you see pokemon pop up and
then you try to catch them that was it
so they over promised and under deliver
however they made so much money on just
that basic implementation that they
delivered that they were able over the
course of five years to build an
application that met their initial
target
requirements
and they built a community around their
application that continues to grow today
so that's one way
to think about looking at your
application
now in uh
take that same model and flip it they
came out with another
mobile application for harry potter uh
wizards unite that completely flopped
similar concept similar premise
different genre
they just could not get it to take off
it just was
basically they missed their mark the the
application itself did not meet the
expectations of the customer and because
of that after a couple years that
application is basically dead it has
almost no development whatsoever and
ensure the servers are still alive
so those are kind of two examples one of
how you can kind of quickly get to
market
unfortunately you over promise under
deliver whereas another one you
basically deliver something that was
promised but ended up being something no
one wanted
good questions
no but that's a good little
follow-up is the
which sort of goes into dave's question
too is it's it is always the thing that
sort of that balance of
do we
now we've talked about this a lot
actually do we you know shoot for 100
or
and wait longer or
do we
cut some corners and push this thing out
yeah it goes back to you know lots of
discussions we've had about code
coverage and things like that but
you know sometimes it's
uh it's also it's not the
amount of bugs it's just which bugs you
know it's it's
you're gonna have like those two games
are examples where you have stuff where
it's
if you've got something that's pretty
new or in an environment that's that's
changing or challenging then you're
going to have issues it's just sort of
nature of the business
but
if you can solve a couple of the big
problems and do those consistently
and not take off your users then you've
got a lot better chance for success it
actually sort of buys you time then to
come back and then
get the smaller details
exactly and
that's kind of why i wanted to do this
presentation to begin with because i
wanted us to kind of revisit
the whole software development life
cycle that software test life cycle but
from a higher level like take a step
back and look at it from the
not just the customer level but also
look at it from the development the
business model you know how are we
actually looking at the whole
development process
very good
all right so let's quickly recap so in
today's presentation we walked through
kind of the whole software development
process from the business level we
started out with talking about a problem
in our particular case you know building
a classroom or course application we
talked about different ways of breaking
down the problem looking at roles uh
who's going to use the application what
type of features you want in the
application you know what type of
frameworks and architectures do you want
to need databases
to different components
so by breaking down the problem into
smaller pieces it allows us to
kind of pick and choose the different
features that we want to roll out in our
application quickly
we then talked about designing the
application kind of doing those
storyboarding the wireframes of the
application can i get the look and feel
of the application before we actually go
out and start building
because if we do this first and we do it
right when we get to the prototype phase
actually writing the application putting
it together we should hopefully reduce a
lot of that overhead a lot of that scope
creep and keep our costs low and get the
product to market quickly
we then also talked about testing and
how that we need to go through and
actually test the application not just
from the user endpoint but test
different things like integration use
different types of testing tools making
sure that things work
so as long as the application works
then we can move into the last the next
two stages which is okay once the
application is done once ready to
deliver we deploy the application we
push that red button we launch the
application
and then the software goes live
and then once everything is out there
once we start um fixing some of the bugs
that are reported by the customer we
talked about the handoff and next steps
where we either deliver the software to
the end user
if we're our own customer or our own
producer we could deploy our application
to the app stores and then our customers
could start downloading our apps
and then what kind of you know what's
the next step what type of features do
we need to start including after this
you know what type of additional support
do we need if we start getting a lot of
calls because there's potential problems
or potential features requests you know
do we need to start a marketing campaign
to start promoting our application
so these are the
overall steps that we go through during
the process of software development
and as always i'd like to thank you all
for your time
and we appreciate you joining us and if
you want to discuss any of our topics
further not just software development
but anything from our website you can
send us questions comments or
suggestions through any of these uh
areas we are on email info development
dot com you can reach us on our website
we have a contact us page we're on
twitter at developer nur we are on
facebook at
facebook.comdeveloperner and if you'd
like to check out any of our other
videos and podcasts you can check us out
on developer.com
our videos are also on vimeo.com
developerner and you can find us on
youtube if you go to youtube and in the
youtube search type developer
our goal is making every developer
better have a wonderful day
[Music]
you