Detailed Notes
This short gives some reasons for investing time in your Software Development Life Cycle (SDLC) knowledge. This is something you can benefit from no matter your position along the way or even if you are outside the cycle as a user, owner, or entrepreneur.
Transcript Text
thank you [Music] in the past we have talked about the software development life cycle and a couple of recent courses and reviewing some of that content has me thinking about that a little bit more as far as how does it really apply to software developers and particularly the better software developers is it something that is really just a an academic kind of exercise or is there more to it now the software development life cycle I think is a foundation for good developers is the foundation of what they do you may think of it as sort of a you know just a simple checklist of hey we do these things these are pieces of software development and in a sense they are however when you do those things better your software will be better sometimes that's very obvious for example implementation if you write good code if you can create a good product it's going to be a good product you know it sort of follows however understanding the whole process and doing it better is important and this is why we put together a class that is a very simple one you can spend about an hour and understand it better or you can go into a deep dive and understand it even better and it was that question of why even bother because hey most people can after a while they can sort of figure out the sdlc but there is more to it there is value out of each of those steps so Gathering requirements we go to gather requirements there is a an art basically to properly Gathering requirements there is there are you know templates and things like that that we can use but also the way we go about it the process itself is critical in US Gathering all of the requirements that we need to and while you may say okay we can always catch up later if we miss something we'll find it you know somewhere further down the road but one that has a higher cost it's easier it's better it is more efficient to get our requirements gathered up front but more importantly we want to be able to get the level of detail we need for those requirements so they can be properly designed and implemented and tested so Gathering requirements is not just like uh you know creating a list and hey we're off and running it really is starting with that list and then digging into it and understanding it so that we can build a solution that is not just what we are asked for but what actually solves the problems that our users or customer needs to have solved now software design sort of the same thing you can throw something together fairly quickly and say yep here it is here's some features and things of that nature but if you don't spend enough time if you don't go into enough detail there's going to be gaps and then those are gonna it's gonna cost time and it's gonna be frustrating to fill those gaps in but also there's going to be a servicing of issues that maybe are not correct the best way to describe this is building software that nobody ever uses it's not necessarily because you didn't solve the problem they want solved it's because maybe it wasn't solved in a right way maybe it wasn't a very useful approach maybe it is in more trouble than it's worth to use your approach to solving their problem and so designing software has something to do with it requirements does as well but when you design software properly you're keeping those users in mind you are going through some you know basically some steps and some templates and sort of some approaches that help you better put yourself in the shoes of your user and therefore design a better solution and it's also that technical side is you want to be able to design something that the implementers can Implement that they can code that will help have help with a scalable maintainable High performing solution when we get done now of course implementation is I think everybody would look at it and say particularly because it's so much a part of the sdlc as far as time and resources spent everybody would say hey if we can get better at implementation then we can get better at building software of high quality and scalable and all those good things but there's also approaches to implementation that help ease that they Grease the skids for getting implementation done correctly it has to do with things like communication and setting some sort of you know proper setting of expectations and planning and estimation and some things like that that we can all spend some time in a general sense talking about implementation learn a little bit more about how that fits in and find some ways to be better developers by being better implementers now testing is it is something that has not been historically maybe given the the weight the gravitas that it needs but is now becoming more and more a part of development the modern shops have especially if you go to continuous integration and deployment but even without most shops now most platforms have built in this expectation at least that you're going to be doing unit tests and you're going to have regression testing and you're probably going to have some level of of system testing and validation so that when you deploy your software our goal now is as it always was but now we have tools to do so which is to deploy something that that works that if it has bugs we can more easily track those down communicate those get those fixed re you know retest it or validate the fix and then move forward so testing and especially in the world of sdlc even if you're not a tester per se a QA resource then it's still very helpful even all the way back if your specialty is gathering requirements is very useful to understand what the testers are doing and how they do it and some of their best practices and processes and procedures because that's going to help you do a better job fleshing out those requirements and of course you think about design a better design that is now communicated to the testers so that the whole process is much smoother flows better and you essentially not only help yourself do your job better you help them do their job better which comes back to now everybody wins now deployment is something that is definitely grown in complexity and I think it's worth it for all of us even if we're not a deployment expert of some sort to understand what can go into it because particularly again going back to requirements and design and even implementation there are things we can do that we'll say helps that along and there's also things we can do that hinders our deployment efforts we can overarch architect things we can make things more complex than they need to be and then that's going to cause headaches down the road and it may impact everybody along the way that testing even you know the testing now is starting to be sort of built into deployment in a lot of cases or at least some facet of it particularly like deploying into a staging environment or something because you'll you know commit your code and then there'll be some tests some sort of a test brace that runs against it and either says yep you passed or you didn't and either you move forward or you fix it doing those things and having as far as like testing and things like that and having deployment in mind and vice versa is really really important it is a critical step in being able to do those things better to do them efficiently and understand what are the the moving parts that we have to be aware of we are building some of these systems and testing them and you know all the way back to designs and requirements it's what what is it that we need to do to bring all of these things together so that when we get done we can put it in front of a user and what your deployment does in a way that is useful to them and in a way that is easily reproducible and something we can validate so even deployment which sometimes is not terribly complex it may just be copying a file from point A to point B but still understanding that better and what can go into that even if your software maybe doesn't take advantage of the the complexities of modern deployment where you can have things going out to different mobile applications you have database updates and you can have API updates and you can have all these integration updates and just it can go on and on understanding that whether you have a simple or complex deployment is yet another way to better do software to build software better and we get into that last sdlc step of maintenance thinking about this cycle idea of sdlc you know the C in sdlc software development life cycle that cycle part and how we maintain our software which is like security updates and simple things like that and maybe minor bug fixes but then also enhancements and how we cycle into our essentially our next version whether it's a point version or a you know a major or minor release things like that depending on your terminology for how you build software and particularly now when we get into this much tighter cycle approach to software development is not uncommon to have an MVP and then you know a month or two later you've cycled through and now you've got MVP Plus One or whatever it is you've got this next iteration of that mvp because you got it you built it you got your minimally viable product you got it out to market now you want to start enhancing it and building on top of it so understanding that we go through all this and then we basically can start back over again Gathering requirements is I think critical particularly for long-lived healthy growing software because as we go through a cycle we have that we can have that next cycle in mind it's on our radar and therefore we can be doing things to help us in the next cycle we can already be putting together some requirements we can making maybe make some design changes things of that nature that will make if not this software cycle better it will make us better as we go and of course there's methodologies that sort of enforce this or help us do this and those are some of the things that are often talked about in sdlc courses and introductions and which we cover as well we talk about some things out there and we even go very deep into you know the very popular scrum and talk about agile and things of that nature so software development life cycle is I think very critical for it gives us a Common Language for anybody involved with software development so even if you're not a developer if you're requirements Gathering like business analysts or something like that if you do software design if you do software implementation if you're a tester if you do deployment if you are a product owner if you are a business person that is thinking about building software or has some connection to software within your organization whether it's building or whether it's buying it and customizing it stlc has a lot of value it is something that gives us that common language that we can talk about all of these complex processes and actually communicate what it is that we want and what our goals are without it then it falls into this thing that we've seen in the past where people just struggle to communicate what they want or communicate what they think is being asked for and then you just spend too much time trying to clarify and get people on the same page if you can get everybody understanding sdlc it is a very good step in being able to properly communicate and be on the same page about your software and product so thanks for your time thanks for listening in as always if you have any questions shoot us an email at info developmentor.com check us out at developmentor.com school.developer nord.com if you want to do want to learn more about sdlc and check out even we've got a free course with a nice little quick reference you can check us on Twitter at developreneur we're out here just trying to find ways to build better developers make better developers and and whether we can do that directly with developers or in the interactions they have with with entrepreneurs and business owners and Specialists and subject matter experts and all that however we can do it we are happy to do so because when the developers get better when they do better software it helps the business become better you become more efficient and you do so at lower cost and with some confidence that you're going to hit your targets of of time and budget thanks a lot for your time hope you go out there and have yourself a great day hello this is Rob with developing or also known as building better developers wanted to announce that we have school.developmentor.com feel free to check it out if you like any of this information any of the content that we've sent and you would like to see more you can come out you can enroll for free we have free courses we've got places for you to get better at just learning a technology our how to's you can work on your business skills we can help you with becoming a better developer as encoding and things like that a lot of the stuff you've seen on YouTube we also have out at school.developmentor we just have it a little more of a educational format and a way for you to track your progress as you move forward becoming a better developer foreign
Transcript Segments
thank you
[Music]
in the past we have talked about the
software development life cycle and a
couple of recent courses and reviewing
some of that content has me thinking
about that a little bit more as far as
how does it really apply to software
developers and particularly the better
software developers is it something that
is really just a an academic kind of
exercise or is there more to it
now the software development life cycle
I think is a foundation for good
developers is the foundation of what
they do
you may think of it as sort of a you
know just a simple checklist of hey we
do these things these are pieces of
software development and in a sense they
are
however
when you do those things better your
software will be better
sometimes that's very obvious for
example implementation if you write good
code if you can create a good product
it's going to be a good product you know
it sort of follows however
understanding the whole process and
doing it better is important and this is
why we put together a class that is a
very simple one you can spend about an
hour and understand it better or you can
go into a deep dive and understand it
even better
and it was that question of why even
bother because hey most people can after
a while they can sort of figure out the
sdlc
but there is more to it there is value
out of each of those steps
so Gathering requirements we go to
gather requirements there is a an art
basically to properly Gathering
requirements there is there are you know
templates and things like that that we
can use but also the way we go about it
the process itself is critical in US
Gathering all of the requirements that
we need to
and while you may say okay we can always
catch up later if we miss something
we'll find it you know somewhere further
down the road but one that has a higher
cost it's easier it's better it is more
efficient to get our requirements
gathered up front
but more importantly we want to be able
to get the level of detail we need for
those requirements so they can be
properly designed and implemented and
tested so Gathering requirements is not
just like uh you know creating a list
and hey we're off and running it really
is starting with that list and then
digging into it and understanding it so
that we can build a solution that is not
just what we are asked for but what
actually solves the problems that our
users or customer needs to have solved
now software design
sort of the same thing you can throw
something together fairly quickly and
say yep here it is here's some features
and things of that nature
but if you don't spend enough time if
you don't go into enough detail there's
going to be gaps and then those are
gonna it's gonna cost time and it's
gonna be frustrating to fill those gaps
in
but also there's going to be
a servicing of issues that maybe are not
correct the best way to describe this is
building software that nobody ever uses
it's not necessarily because you didn't
solve the problem they want solved it's
because maybe it wasn't solved in a
right way maybe it wasn't a very useful
approach maybe it is in more trouble
than it's worth to use your approach to
solving their problem
and so designing software has something
to do with it requirements does as well
but when you design software properly
you're keeping those users in mind you
are going through some you know
basically some steps and some templates
and sort of some approaches that help
you better put yourself in the shoes of
your user and therefore
design a better solution and it's also
that technical side is you want to be
able to design something that the
implementers can Implement that they can
code that will help have help with a
scalable maintainable High performing
solution when we get done
now of course implementation is
I think everybody would look at it and
say particularly because it's so much a
part of the sdlc as far as time and
resources spent
everybody would say hey if we can get
better at implementation then we can get
better at building software of high
quality and scalable and all those good
things
but there's also approaches to
implementation that help
ease that they Grease the skids for
getting implementation done correctly it
has to do with things like communication
and setting some sort of you know proper
setting of expectations and planning and
estimation and some things like that
that we can all spend some time in a
general sense talking about
implementation learn a little bit more
about how that fits in and find some
ways to be better developers by being
better implementers
now testing is
it is something that has not been
historically maybe given the
the weight the gravitas that it needs
but is now becoming more and more a part
of development the modern
shops have especially if you go to
continuous integration and deployment
but even without most shops now most
platforms have built in this expectation
at least that you're going to be doing
unit tests and you're going to have
regression testing and you're probably
going to have some level of of system
testing and validation so that when you
deploy your software
our goal now is as it always was but now
we have tools to do so
which is to deploy something that that
works that
if it has bugs we can more easily track
those down communicate those get those
fixed
re you know retest it or validate the
fix and then move forward
so testing and especially in the world
of sdlc even if you're not
a tester per se a QA resource then it's
still very helpful even all the way back
if your specialty is gathering
requirements
is very useful to understand what the
testers are doing and how they do it and
some of their best practices and
processes and procedures because that's
going to help you do a better job
fleshing out those requirements and of
course you think about design a better
design that is now communicated to the
testers so that the whole process is
much smoother flows better and you
essentially not only help yourself do
your job better you help them do their
job better which comes back to now
everybody wins
now deployment is something that is
definitely grown in complexity and I
think it's worth it for all of us even
if we're not a deployment expert of some
sort to understand what can go into it
because particularly again going back to
requirements and design and even
implementation
there are things we can do that we'll
say helps that along and there's also
things we can do that hinders our
deployment efforts we can overarch
architect things we can make things more
complex than they need to be
and then that's going to cause headaches
down the road
and it may impact everybody along the
way that testing even you know the
testing now is starting to be sort of
built into deployment in a lot of cases
or at least some facet of it
particularly like deploying into a
staging environment or something because
you'll you know commit your code and
then there'll be some tests some sort of
a test brace that runs against it and
either says yep you passed or you didn't
and either you move forward or you fix
it
doing those things and having as far as
like testing and things like that and
having deployment in mind and vice versa
is really really important it is a
critical step in being able to do those
things better to do them efficiently and
understand what are the the moving parts
that we have to be aware of we are
building some of these systems and
testing them and you know all the way
back to designs and requirements it's
what
what is it that we need to do to bring
all of these things together so that
when we get done we can put it in front
of a user and what your deployment does
in a way that is useful to them and in a
way that is easily reproducible and
something we can validate
so even deployment which
sometimes is not terribly complex it may
just be copying a file from point A to
point B but still understanding that
better and what can go into that even if
your software maybe doesn't take
advantage of the the complexities of
modern deployment where you can have
things going out to different mobile
applications you have database updates
and you can have API updates and you can
have all these integration updates and
just it can go on and on
understanding that whether you have a
simple or complex deployment is yet
another way to better do software to
build software better
and we get into that last sdlc step of
maintenance
thinking about
this cycle idea of sdlc you know the C
in sdlc software development life cycle
that cycle part
and how we maintain our software which
is like security updates and simple
things like that and maybe minor bug
fixes but then also enhancements and how
we cycle into our essentially our next
version whether it's a point version or
a you know a major or minor release
things like that depending on your
terminology for how you build software
and particularly now when we get into
this much tighter cycle approach to
software development is not uncommon to
have an MVP and then you know a month or
two later you've cycled through and now
you've got MVP Plus One or whatever it
is you've got this next iteration of
that mvp because you got it you built it
you got your minimally viable product
you got it out to market now you want to
start enhancing it and building on top
of it so understanding that we go
through all this and then we basically
can start back over again Gathering
requirements
is I think critical particularly for
long-lived healthy growing software
because as we go through a cycle
we have that we can have that next cycle
in mind it's on our radar and therefore
we can be doing things to help us in the
next cycle we can already be putting
together some requirements we can making
maybe make some design changes things of
that nature that will make if not this
software cycle better it will make us
better as we go
and of course there's methodologies that
sort of enforce this or help us do this
and those are some of the things that
are often talked about in sdlc courses
and introductions and which we cover as
well we talk about some things out there
and we even go very deep into you know
the very popular scrum and talk about
agile and things of that nature so
software development life cycle is I
think very critical for it gives us a
Common Language
for anybody involved with software
development so even if you're not a
developer if you're
requirements Gathering like business
analysts or something like that if you
do software design if you do software
implementation if you're a tester if you
do deployment if you are a product owner
if you are a business person that is
thinking about building software or has
some connection to software within your
organization whether it's building or
whether it's buying it and customizing
it
stlc has a lot of value it is something
that gives us that common language that
we can talk about all of these complex
processes and actually communicate what
it is that we want and what our goals
are without it then it falls into this
thing that we've seen in the past where
people just struggle to communicate what
they want or communicate what they think
is being asked for and then you just
spend too much time trying to clarify
and get people on the same page if you
can get everybody understanding sdlc it
is a very good step in being able to
properly communicate and be on the same
page about your software and product
so thanks for your time thanks for
listening in as always if you have any
questions shoot us an email at info
developmentor.com check us out at
developmentor.com school.developer
nord.com if you want to do want to learn
more about sdlc and check out even we've
got a free course with a nice little
quick reference you can check us on
Twitter at developreneur
we're out here just trying to find ways
to build better developers make better
developers and and whether we can do
that directly with developers or in the
interactions they have with with
entrepreneurs and business owners and
Specialists and subject matter experts
and all that however we can do it we are
happy to do so because when the
developers get better when they do
better software it helps the business
become better you become more efficient
and you do so at lower cost and with
some confidence that you're going to hit
your targets of of time and budget
thanks a lot for your time hope you go
out there and have yourself a great day
hello this is Rob with developing or
also known as building better developers
wanted to announce that we have
school.developmentor.com feel free to
check it out if you like any of this
information any of the content that
we've sent and you would like to see
more you can come out you can enroll for
free we have free courses we've got
places for you to get better at just
learning a technology our how to's you
can work on your business skills we can
help you with becoming a better
developer as encoding and things like
that a lot of the stuff you've seen on
YouTube we also have out at
school.developmentor we just have it a
little more of a educational format and
a way for you to track your progress as
you move forward becoming a better
developer
foreign