Detailed Notes
In this episode, we delve into the next step in the developer journey: implementation. We explore how to work within different team sizes and structures, including individual projects, small teams, and large teams. This guide will cover essential strategies for maximizing efficiency in various software development environments.
Read more ... https://develpreneur.com/maximizing-efficiency-in-software-development-individual-small-and-large-teams
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources
* Embrace Feedback for Better Teams (https://develpreneur.com/embrace-feedback-for-better-teams/)
* Using Offshore Teams and Resources – Interview With Tanika De Souza (https://develpreneur.com/using-offshore-teams-and-resources-interview-with-tanika-de-souza/)
* Moving To Mobile Teams and Building Them – Sebastian Schieke (https://develpreneur.com/moving-to-mobile-teams-and-building-them-sebastian-schieke/)
Transcript Text
[Music] not this hey everybody we record so we are recording uh this episode Let's see we want to talk about see throwing a couple ideas out here places to look for work and how to leave a job professionally when when quitting or resigning uh let's see uh development Journey on working on teams agile waterfall stuff like that um what were you thinking about from the like the you mentioned something about the you know they working on development the the journey and working on teams agile waterfall stuff what were you where were you thinking that would that conversation would go so we've had the you know what makes a developer you know what when do you reach the point of be you know becoming a developer when do you know you're a coder we talked about solving problems being a problem solver we talked about um solving problems without solving problems and I thought the next progression would either be you know about the teams or potentially about software development you know like how do you so we've talked about you know solving the problems but now maybe talking about in a more constructive way like all right so you may be coming out of those boot camps out of school you know how do you actually build software what are the types of environments you can work in as far as teams go like agile a waterfall structure you know startup kind of mentality uh kind of ideas on maybe talk about you know some of the lessons we learned from you know when we started out you know like we said before you know you jump into a team you got to learn how to write the code this way but go One Step Beyond what we talked about already as far as like coding but now talk about working in the teams writing the code kind of what's involved uh yeah let's see where that goes I think we can give it a shot um and we'll see where that where that takes us because I think there's a lot of ways we can go with that that's another one there's a lot of different directions so I'll kick it off and then you can either reain it in or you can wander off on a different Rabbit Trail if that if that happens to be the case so we'll see how that goes okay well hello and welcome back we are continuing our season and we are talking about the developer Journey uh my name is Rob Broadhead I am one of the founders of developing or building better developers and on the other side is Michael you go ahead and introduce yourself because you do it so much better than I do hey everyone my name is Michael Mage I'm one of the founders of develop prur and I'm also the founder of Envision QA so if you need custom software or testing call out to us so this episode we're going to look at sort of a sort of The Next Step that we've T we've sort of been working our way through the developer journey and some of those things we're going to look a little bit into uh we look at like implementation but it's really about implementation about like whether you're within a team and how do you work within that team and what's the difference and not really necessarily the difference but some of the things that may come up such as whether it's an agile shop or a waterfall model or a we'll talk a little bit I think we'll see how this goes about things like whether you're remote or you're not and all of the things that you may run into that you would not have hit probably while you were in school or while you were on a boot camp or or going through an online course or whatever it was that you were doing however you got your basic skills now this is when the skills hit the real world when the rubber meets a road and you get out there and and talk a little bit about that and so my thought with this first comes first thing that came to mind as as we were talking through this concept or this idea this topic is the difference between uh Team sizes is basically whether you're it's you which sometimes happens particularly it's a side hustle or something it may be really you are really the only developer working on it or it's something where you're in a small team and usually it's GNA be small team with small high communication kind of team because it's usually you know two or three of you everybody's got to really has to communicate or else it's going to fall apart and then I think another big step was when you get into a team that's a and what people think of more of like an actual team where you've got you know half dozen dozen or more people that there's different roles and things like that so really the three places are individual where each your Chief cook bottle washer small team where everybody is basically wearing all the hats and they're just sort of working together in a in a very tight-knit group and then when you get into something a little bigger where you do have defined roles which could be number-wise I guess you could have a team of like five people where you have a dedicated you know maybe a QA person a dedicated database developer dedicated API developer I want to talk a little bit about those and what you need to think about in order to make the most of the team the one that'll be really quick and easy or at least quick and I'm going to you know sort of fly through it is individually individually I think when you step into a project and this is most important if you're doing a side hustle or something like that where you or maybe you've get ass sign by your boss to go to a proof of concept or a demo or something where like hey go build this thing and then come back when you're done or something along those lines I we've talked about it before I cannot emphasize enough use that as an opportunity to practice the common development things like committing code putting decent Comm you know comments on your your commits commenting your code having a a reproducible build process of some sort it is easy as an IND idual to sort of just skirt those things to just like write code and then you just build it and you copy it and all that but you're this a great place for you to cut your teeth on having like processes and reproducible repeatable things that you do as part of your process so that you can be a better developer for example I think I've mentioned before that I use ant scripts a lot that's just something I've had for a long time I like them I've been able to make them do all kinds of cool stuff uh including like I can rebuild my database I can copy files out I can restart stuff on servers all of that and while I don't really technically need those things and I just air quoted for those of you that are can't see me visually but they are very valuable it is amazing over time how much those little scripts will save you now it may be you know a minute here or a minute there but it'll save you typos it'll make it reproducible and that time does you know it does add up as you go day after day and you know build after build and push after push over time that stuff adds up and so utilize that make the most of the tools that are out there small teams a small team really I think if you have not introduced yourself to slack or teams or something where there's a chat some sort of instant messaging thing you really need to do that uh I currently have a small team I'm working on we've got and we do have defined roles of more or less as we've got sort of front end middle API backend kind of developers but because we are building something that is you know we're working towards a version one we'll call it we need to there's a lot of changes going on so it's not like the API is stable it's not like the UI is stable it's not like anything is stable we're constantly changing and adding features those kinds of situations you need to have a way set up that you can communicate and make sure that everybody's on board with that communication style so if it's if it's a slack Channel or slack make sure that everybody has slack up and that they know when it's you know we all know when we're working because that can also be a big problem when you get into bigger teams as well but especially small teams if you're waiting on the the database developer and they only work 2: a.m. to 6:00 a.m. your time then you can can lose days sometimes because you're waiting for them and you got to go send them something you got to make sure that you've got a very good communication structure that you understand that timing and it may be something where you know some people may have to get a little bit out of their comfort zone and check things outside of their normal schedule just to help you if not know that that's going to be a blocker at some point you know if you've got somebody that doesn't show up on a Thursday that they always take Thursdays off and they're not there inevitably there's going to be a point where their code change is required on a Thursday and that means you're going to have to wait till Friday so make sure that you're clear on those things last thing and then I'm going to kick it over to you Michael is the big team stuff all of the things I've talked about in these other two instances are really important in the big team stuff but the biggest thing that I think I have seen that's a a gap or a flaw in larger teams is ownership is making sure when you line up your project and you say here's the requirements and here's what we're going to do and this is the structure and this is the architecture and all that stuff all of the pieces all of the steps within the software development life cycle all of the main we'll call them like feature uh you know feature points and stuff like that there needs to be somebody somewhere that owns those things and by own I mean there's somebody that is a decision maker of some sort and if they aren't that you can go to them and you can say hey we need to have we have a question about this and they need to be able to go to the person that can answer that and also somebody that's when you get towards the end in particular they're going to be able to do things like test it and validate it and say yes that is correct or if a test fails they need to be the person that can override that and say oh no that's okay we've changed it or say yes that's critical and particularly when you get into the go noo meetings of is this going to be you know is this production worthy you've got to have those people there and so often that is a gap as you get into larger teams where there's something just nobody owns it and that may include the project plan itself deadlines all kinds of stuff that is critical to declaring something done uh which is probably the the most basic of that when you go into a project particularly with the team we need to all agree what does done look like what does that mean because done is different to everybody else and now I am done and my definition is I want to let let you throw your your two cents and actually due to inflation is now your 45 bucks into the conversation Mike so you've touched on the three different types of teams you talked about the independent person working on a team could be a contract could be a startup uh whatever but it's essentially a team of one uh you talked about the small mid size teams small development teams communication and you talked about the large teams now the running theme of all three of those uh at least between the midsize and large is communication now even if you're an individual of one communication is still important but the communication typically is more important between you and the customer or you and the vendor because you have to make sure that what you're working on is done right now with all three of those the types of ways you work on the projects or you develop software typically can follow the same type of pattern you have things like waterfall where you build the entire project in one go and then you have small deliverables as you go out and get user feedback as you're building the application typically you see a little bit more of that with individual or even startup mentalities uh but typically in today's environment it's more agile driven you do things in small Sprints you get things out the door quickly this really is tailored for any type of team or environment you typically want to start quickly you you define your requirements and you start chipping away at it in small iterations and deliverables as you're doing this regardless of what size team you're working on make sure you follow some simple steps one make sure that you understand the requirements that you need you understand the software that you're building make sure you have good documentation skills make sure you comment your code and you follow some best practices you know make sure you write test cases for your code make sure you have the user stories defined as you're building this software now Circle back around as you're communicating this if you're dealing with offshore or different time zones with teams this type of strategy really can hit home because if you're doing small deliverables no one should be working on anything that isn't related to the current Sprint so you really should be working on requirements in such a way that you don't have too many blockers now this can happen but if you're in this agile environment when you're communicating you hit a blocker everyone's on the same page it's like whoops hey we've got this problem let's kind of circle the fences and work through it now that kind of the development style now as Rob said you know if you're a standalone regardless of what team code backup code repositories are critical make sure that you define and keep backing up your code this can also help with that documentation it can also help with testing so we've talked about testing before in past podcasts but what we really haven't hit home is if you build out that deployment process that continuous integration continuous deployment one of the things you can also build into that like Rob uses ANS scripts to help do his builds his deploys and things of that nature you can also write in to your continuous integration pipeline testing so you can kick off like Jenkin or bamboo so when you deploy your software it automatically kicks off the test to run against your software now as you're compiling your code you can run unit tests against your code to make sure that the white box testing of your code works that the functions work the way they're supposed to when you're deploying it through the continue integration process you're looking at more kind of like blackbox testing you're testing things on the backend so you can write those integration tests those regression tests those smoke testing and even system and load testing all that can be built into the process as you're going through your software development process this really works in any environment it could be waterfall it could be agile but typically you want to think agile try to get away from that monolithic application now you could be in that situation if you did a proof of concept and oops you're now in production you kind of have to backtrack a little bit so if you run into situations like that again work with the tools you have if you don't have good tools or good software development processes in place look at project management tools like Microsoft project jira uh bugzilla you even have some uh I believe issue tracking Tools in git laabs now so look at using these to help manage your process to manage the project and make sure everyone's on the same page and finally the last point I'd like to hit on is while you're working in teams now if you're working in a ASO is you you have to hold yourself accountable so time management becomes critical you should be keeping track of what you're working on so things don't get off the rails again that falls into that agile process now when you're dealing with small to midsize teams or even larger teams uh time management kind of gets a little managed by the team environment you have like your daily scrums you have your standups you have your team collabs which kind of keeps everyone moving in the same direction and keep things on track so something's falling behind you call it out and people you know again help circle the wagons and we can work together and keep things moving forward so I'll pass that back to you now Rob since I've kind of rambled on for a bit I think that the one thing I wanted to to point out to this that I I I have seen uh a change in this there are going to be times when it is all hands on deck there are if you're in a any kind of a real software development whether it is you doing some sort of you know side hustle thing or whether you're doing something with a team of thousands there is a point where there is a push where there there are going to be deadlines there are Milestones or deadlines or cost related to them there's all kinds of things like that one of the things you want to do as much as possible with these pieces the reason that we do this testing and that is to try to level those out as much as possible to try to take early on the where we we don't have this usually the urgency and sometimes there's some stuff that can get done very easily that we take the the buffer that gets built into that and we pull into that some of the things that are a little tougher this is where agile actually becomes very useful because you have things like you have a you have a Sprint you have a short period of time everything has essentially sort of a a critical level to it to some extent we want to get it done get it in this Sprint the two things I'll say is one within your Sprints yes you probably are going to have stuff in any given Sprint that is going to get pushed to the next one make sure that you're not just push push push push and that you're suddenly building up you're building more and more each time that you're just saying ah we're going to punt it to the next Sprint we're going to punt to the next Sprint there is a point where these things come you know come due and you need to get it done and that also means that there are going to be times that if you are a developer this to me is very much a difference when you become a developer is there's a point where like you're going to have late nights you're going to have weekends you're going to have times when things just don't work you're going to have and the worst are probably the configuration types things where I'm setting up a server or you know building this little piece of code that should be done in 30 seconds and it's not and you can lose an insane amount of time one suck it up buttercup you're gonna have to do that but two the good and the bad news I guess it's mostly bad news that never ends there will be times like Michael and I have been doing this for decades and we have still had times I know both of us even in the last few months where something like that happens and it's you know something is the uppercase instead lowercase or like I had one I chased down the other day it was literally a nine versus an 11 in two lines of code that were in a configuration file and it was like buried deep in a you know took a while to find it kind of thing those things happen just realize that is part of why they you know as they say you get paid the big bucks or whatever it is even if you're not getting paid the big bucks this is like part of what we we do have to struggle through and so the more that we communicate the more that we put all of these I will call them for lack of better term best practices into practice the more likely we are that we're not going to hit those kinds of things because we're going to test earlier we're going to see the bugs earlier we're going have repeatable processes and all the things that often contribute to those typos and those kinds of errors that cost a lot of time and caus us a lot of headaches and cost you know night all nighters and things like that we will get those things out of way there's a reason for this this is done by people and if if you do it often enough you will do it yourself because you'll be a believer because you'll realize that darn it if I had written a little script if I'd taken you know know five minutes and written a little shell script to do that then I would not have had that typo that cost me three hours to go track down uh closing thoughts on you and then we'll wrap this one up yeah so I'd like to add one additional thing to the idea of stuff getting kicked down the road like Pro you know um tasks taking more than one Sprint one thing that can occur and it does occur a lot in software development is someone comes up with an idea sales talks to a customer and within the course of the current development cycle you tend to get what's called scope creep you get new things added that are not necessarily thought out and it can cause things to really start going off the rails which causes the backup if you start encountering that if you can push back and try to get that into the next release cycle so you can finish the current level of work sometimes you can't but if you can will help keep a divide between the different areas of work being done uh otherwise SC Creek really big problem could potentially derail an application or it could really push your deliverables off track the other thing I'd like to touch on just slightly so we talked about the idea of projects you know those late nights and having to be all hands- on Deb sometimes that is the fault of the software sometimes a bug gets found but sometimes this could be something that is totally unintentional and and kind of a side effect of something else going on somewhere else in the company a real quick example of that is years ago we both worked at a company uh this was before Rob came on but we were going through a major systems upgrade behind the scenes and they had it all ready to go all tested and they were about to turn it on when we found out it did not work with our current web application software they forgot to test it literally 10 days before they went live because they had to go live for a federal requirement we had to completely overhaul our application server install a brand new updated server to work with everything and literally we were working almost 24 hours 10 for 10 days to make this happen we were talking to support in every time zone from Germany to Japan to California I mean it happens don't panic when that happens you're going to have a lot of anxiety trust me but just understand what the problem is make sure you have the numbers of who you need to talk to the support people and work together you know basically it's not necessarily one person's uh problem to solve unless you're a one person shop but it's the the help of the team it takes a community to kind of get you through this these kind of problems so use that and don't you know don't fall on your sword and be the only person that oh my God I have to figure this out work as a team I think that's the probably The Parting thought that I want to put into this is that yes this sounds you know we're painting not a very happy picture but these are also the times that you bond with your team these are the like these are the Box hole moments and stuff like that where you go through this stuff and you will come out of it on the other side I think a little closer tighter um it is really a good team building kind of experience so don't you know don't freak out it happens life continues you're going to have you will sleep again you know stuff like that unless it's a Death March and that's a whole different problem we'll talk about those another time because when we're just want to have another cheery discussion like this that being said if you're feeling really cheery right now and want to give us some feedback please shoot us an email info developer.com you can request things that you want us to talk about you can give us feedback you can trade War Stories whatever it is we'll read it we may probably will actually at some point refer to it on uh on the YouTube channel or out on the podcast you can also check us out on develop ur.com you can enter information in our forums there's a contact there's a contact us form there you can send us stuff on Twitter X you can leave us comments here you can leave us comments on YouTube you can check us out on YouTube if you're not and if you're on YouTube and you're then you can check us out on our podcast all of that being said we are not done I know that's a shocker we're coming back we're going to have more information more things to discuss next time around so until the next time go out there and have yourself a great day a great week and we will talk to you next time [Music]
Transcript Segments
[Music]
not
this hey everybody we record so we are
recording uh this episode Let's see we
want to talk
about see throwing a couple ideas out
here places to look for work and how to
leave a job professionally when when
quitting or resigning uh let's
see uh development Journey on working on
teams agile waterfall stuff like that
um what were you thinking about from the
like the you mentioned something about
the you know they working on development
the the journey and working on teams
agile waterfall stuff what were you
where were you thinking that would that
conversation would go so we've had
the you know what makes a developer you
know what when do you reach the point of
be you know becoming a developer when do
you know you're a coder we talked about
solving problems being a problem solver
we talked about um solving problems
without solving problems
and I thought the next progression would
either be you know about the teams or
potentially about software development
you know like how do you so we've talked
about you know solving the problems but
now maybe talking about in a more
constructive way like all right so you
may be coming out of those boot camps
out of school you know how do you
actually build software what are the
types of environments you can work in as
far as teams go like agile a waterfall
structure you know startup kind of
mentality uh kind of ideas on maybe talk
about you know some of the lessons we
learned from you know when we started
out you know like we said before you
know you jump into a team you got to
learn how to write the code this way but
go One Step Beyond what we talked about
already as far as like coding but now
talk about working in the teams writing
the code kind of what's
involved uh yeah let's see where that
goes I think we can give it a shot um
and we'll see where that where that
takes us because I think there's a lot
of ways we can go with that that's
another one there's a lot of different
directions so I'll kick it off and then
you can either reain it in or you can
wander off on a different Rabbit Trail
if that if that happens to be the case
so we'll see how that goes okay well
hello and welcome back we are continuing
our season and we are talking about the
developer Journey uh my name is Rob
Broadhead I am one of the founders of
developing or building better developers
and on the other side is Michael you go
ahead and introduce yourself because you
do it so much better than I do hey
everyone my name is Michael Mage I'm one
of the founders of develop prur and I'm
also the founder of Envision QA so if
you need custom software or testing call
out to
us so this episode we're going to look
at sort of a sort of The Next Step that
we've T we've sort of been working our
way through the developer journey and
some of those things we're going to look
a little bit
into uh we look at like implementation
but it's really about implementation
about like whether you're within a team
and how do you work within that team and
what's the difference and not really
necessarily the difference but some of
the things that may come up such as
whether it's an agile shop or a
waterfall model or a we'll talk a little
bit I think we'll see how this goes
about things like whether you're remote
or you're not and all of the things that
you may run into that you would not have
hit probably while you were in school or
while you were on a boot camp or or
going through an online course or
whatever it was that you were doing
however you got your basic skills now
this is when the skills hit the real
world when the rubber meets a road and
you get out there and and talk a little
bit about that and so my thought with
this first comes first thing that came
to mind as as we were talking through
this concept or this idea this topic is
the difference
between uh Team sizes is basically
whether you're it's you
which sometimes happens particularly
it's a side hustle or something it may
be really you are really the only
developer working on it or it's
something where you're in a small team
and usually it's GNA be small team with
small high communication kind of team
because it's usually you know two or
three of you everybody's got to really
has to communicate or else it's going to
fall apart and then I think another big
step was when you get into a team that's
a and what people think of more of like
an actual team where you've got you know
half dozen dozen or more people that
there's different roles and things like
that so really the three places are
individual where each your Chief cook
bottle washer small team where everybody
is basically wearing all the hats and
they're just sort of working together in
a in a very tight-knit group and then
when you get into something a little
bigger where you do have defined roles
which could be number-wise I guess you
could have a team of like five people
where you have a dedicated you know
maybe a QA person a dedicated database
developer dedicated API
developer I want to talk a little bit
about those and what you need to think
about in order to make the most of the
team the one that'll be really quick and
easy or at least quick and I'm going to
you know sort of fly through it is
individually individually I think when
you step into a project and this is most
important if you're doing a side hustle
or something like that where you or
maybe you've get ass sign by your boss
to go to a proof of concept or a demo or
something where like hey go build this
thing and then come back when you're
done or something along those
lines I we've talked about it before I
cannot emphasize enough use that as an
opportunity to practice the common
development things like committing code
putting decent Comm you know comments on
your your commits commenting your code
having a a reproducible build process of
some sort it is easy as an IND idual to
sort of just skirt those things to just
like write code and then you just build
it and you copy it and all that but
you're this a great place for you to cut
your teeth on having like processes and
reproducible repeatable things that you
do as part of your process so that you
can be a better developer for example I
think I've mentioned before that I use
ant scripts a lot that's just something
I've had for a long time I like them
I've been able to make them do all kinds
of cool stuff uh including like I can
rebuild my database I can copy files out
I can restart stuff on servers all of
that and while I don't really
technically need those things and I just
air quoted for those of you that are
can't see me visually but they are very
valuable it is amazing over time how
much those little scripts will save you
now it may be you know a minute here or
a minute there but it'll save you typos
it'll make it reproducible and that time
does you know it does add up as you go
day after day and you know build after
build and push after push over time that
stuff adds up and so utilize that make
the most of the tools that are out there
small
teams a small team really I think if you
have not introduced yourself to slack or
teams or something where there's a chat
some sort of instant messaging thing you
really need to do that uh I currently
have a small team I'm working on we've
got and we do have defined roles of more
or less as we've got sort of front end
middle API backend kind of developers
but because we are building something
that is you know we're working towards a
version one we'll call it we need to
there's a lot of changes going on so
it's not like the API is stable it's not
like the UI is stable it's not like
anything is stable we're constantly
changing and adding features those kinds
of situations you need to have a way set
up that you can communicate and make
sure that everybody's on board with that
communication style so if it's if it's a
slack Channel or slack make sure that
everybody has slack up and that they
know when it's you know we all know when
we're working because that can also be a
big problem when you get into bigger
teams as well but especially small teams
if you're waiting on the the database
developer and they only work 2: a.m. to
6:00 a.m. your time then you can can
lose days sometimes because you're
waiting for them and you got to go send
them something you got to make sure that
you've got a very good communication
structure that you understand that
timing and it may be something where you
know some people may have to get a
little bit out of their comfort zone and
check things outside of their normal
schedule just to help you if not know
that that's going to be a blocker at
some point you know if you've got
somebody that doesn't show up on a
Thursday that they always take Thursdays
off and they're not there inevitably
there's going to be a point where their
code change is required on a Thursday
and that means you're going to have to
wait till Friday so make sure that
you're clear on those things last thing
and then I'm going to kick it over to
you Michael is the big team
stuff all of the things I've talked
about in these other two instances are
really important in the big team stuff
but the biggest thing that I think I
have seen that's a a gap or a flaw in
larger
teams is ownership is making sure when
you line up your project and you say
here's the requirements and here's what
we're going to do and this is the
structure and this is the architecture
and all that stuff all of the pieces all
of the steps within the software
development life cycle all of the main
we'll call them like feature uh you know
feature points and stuff like that there
needs to be somebody somewhere that owns
those things and by own I mean there's
somebody that is a decision maker of
some sort and if they aren't that you
can go to them and you can say hey we
need to have we have a question about
this and they need to be able to go to
the person that can answer that and also
somebody that's when you get towards the
end in particular they're going to be
able to do things like test it and
validate it and say yes that is correct
or if a test fails they need to be the
person that can override that and say oh
no that's okay we've changed it or say
yes that's critical and particularly
when you get into the go noo meetings of
is this going to be you know is this
production worthy you've got to have
those people there and so often that is
a gap as you get into larger teams where
there's something just nobody owns it
and that may include the project plan
itself deadlines all kinds of stuff that
is critical to declaring something done
uh which is probably the the most basic
of that when you go into a project
particularly with the team we need to
all agree what does done look like what
does that mean because done is different
to everybody else and now I am done and
my definition is I want to let let you
throw your your two cents and actually
due to inflation is now your 45 bucks
into the conversation
Mike so you've touched on the three
different types of teams you talked
about the independent person working on
a team could be a contract could be a
startup uh whatever but it's essentially
a team of one uh you talked about the
small mid size teams small development
teams communication and you talked about
the large teams now the running theme of
all three of those uh at least between
the midsize and large is communication
now even if you're an individual of one
communication is still important but the
communication typically is more
important between you and the customer
or you and the vendor because you have
to make sure that what you're working on
is done right now with all three of
those the types of ways you work on the
projects or you develop software
typically can follow the same type of
pattern you have things like waterfall
where you build the entire project in
one go and then you have small
deliverables as you go out and get user
feedback as you're building the
application typically you see a little
bit more of that with individual or even
startup mentalities uh but typically in
today's environment it's more agile
driven you do things in small Sprints
you get things out the door quickly this
really is tailored for any type of team
or environment you typically want to
start quickly you you define your
requirements and you start chipping away
at it in small iterations and
deliverables as you're doing this
regardless of what size team you're
working on make sure you follow some
simple steps one make sure that you
understand the requirements that you
need you understand the software that
you're building make sure you have good
documentation skills make sure you
comment your code and you follow some
best practices you know make sure you
write test cases for your code make sure
you have the user stories defined as
you're building this software now Circle
back around as you're communicating this
if you're dealing with offshore or
different time zones with teams this
type of strategy really can hit home
because if you're doing small
deliverables no one should be working on
anything that isn't related to the
current Sprint so you really should be
working on requirements in such a way
that you don't have too many blockers
now this can happen but if you're in
this agile environment when you're
communicating you hit a blocker
everyone's on the same page it's like
whoops hey we've got this problem let's
kind of circle the fences and work
through
it now that kind of the development
style now as Rob said you know if you're
a standalone regardless of what team
code backup code repositories are
critical make sure that you define and
keep backing up your code this can also
help with that documentation it can also
help with testing so we've talked about
testing before in past podcasts but what
we really haven't hit home is if you
build out that deployment process that
continuous integration continuous
deployment one of the things you can
also build into that like Rob uses ANS
scripts to help do his builds his
deploys and things of that nature you
can also write in to your continuous
integration pipeline testing so you can
kick off like Jenkin or bamboo so when
you deploy your software it
automatically kicks off the test to run
against your software now as you're
compiling your code you can run unit
tests against your code to make sure
that the white box testing of your code
works that the functions work the way
they're supposed to when you're
deploying it through the continue
integration process you're looking at
more kind of like blackbox testing
you're testing things on the backend so
you can write those integration tests
those regression tests those smoke
testing and even system and load testing
all that can be built into the process
as you're going through your software
development process this really works in
any environment it could be waterfall it
could be agile but typically you want to
think agile try to get away from that
monolithic application now you could be
in that situation if you did a proof of
concept and oops you're now in
production you kind of have to backtrack
a little bit so if you run into
situations like that again work with the
tools you have
if you don't have good tools or good
software development processes in place
look at project management tools like
Microsoft project jira uh bugzilla you
even have some uh I believe issue
tracking Tools in git laabs now so look
at using these to help manage your
process to manage the project and make
sure everyone's on the same page and
finally the last point I'd like to hit
on is while you're working in teams now
if you're working in a ASO is you you
have to hold yourself accountable so
time management becomes critical you
should be keeping track of what you're
working on so things don't get off the
rails again that falls into that agile
process now when you're dealing with
small to midsize teams or even larger
teams uh time management kind of gets a
little managed by the team environment
you have like your daily scrums you have
your standups you have your team collabs
which kind of keeps everyone moving in
the same direction and keep things on
track so something's falling behind you
call it out and people you know again
help circle the wagons and we can work
together and keep things moving
forward so I'll pass that back to you
now Rob since I've kind of rambled on
for a bit I think that the one thing I
wanted to to point out to this that I I
I have seen uh a change in
this there are going to be times when it
is all hands on deck there are if you're
in a any kind of a real software
development whether it is you doing some
sort of you know side hustle thing or
whether you're doing something with a
team of thousands there is a point where
there is a push where there there are
going to be deadlines there are
Milestones or deadlines or cost related
to them there's all kinds of things like
that one of the things you want to do as
much as possible with these pieces the
reason that we do this testing and that
is to try to level those out as much as
possible to try to take early on the
where we we don't have this usually the
urgency and sometimes there's some stuff
that can get done very easily that we
take the the buffer that gets built into
that and we pull into that some of the
things that are a little tougher this is
where agile actually becomes very useful
because you have things like you have a
you have a Sprint you have a short
period of time everything has
essentially sort of a a critical level
to it to some extent we want to get it
done get it in this
Sprint the two things I'll say is one
within your Sprints yes you probably are
going to have stuff in any given Sprint
that is going to get pushed to the next
one make sure that you're not just push
push push push and that you're suddenly
building up you're building more and
more each time that you're just saying
ah we're going to punt it to the next
Sprint we're going to punt to the next
Sprint there is a point where these
things come you know come due and you
need to get it done and that also means
that there are going to be times that if
you are a developer this to me is very
much a difference when you become a
developer is there's a point where like
you're going to have late nights you're
going to have weekends you're going to
have times
when things just don't work you're going
to have and the worst are probably the
configuration types things where I'm
setting up a server or you know building
this little piece of code that should be
done in 30 seconds and it's not and you
can lose an insane amount of time one
suck it up buttercup you're gonna have
to do that but two the good and the bad
news I guess it's mostly bad news that
never ends there will be times like
Michael and I have been doing this for
decades and we have still had times I
know both of us even in the last few
months where something like that happens
and it's you know something is the
uppercase instead lowercase or like I
had one I chased down the other day it
was literally a nine versus an 11 in two
lines of code that were in a
configuration file and it was like
buried deep in a you know took a while
to find it kind of thing those things
happen just realize that is part of why
they you know as they say you get paid
the big bucks or whatever it is even if
you're not getting paid the big bucks
this is like part of what we we do have
to struggle through and so the more that
we communicate the more that we put all
of these I will call them for lack of
better term best practices into practice
the more likely we are that we're not
going to hit those kinds of things
because we're going to test earlier
we're going to see the bugs earlier
we're going have repeatable processes
and all the things
that often contribute to those typos and
those kinds of errors that cost a lot of
time and caus us a lot of headaches and
cost you know night all nighters and
things like that we will get those
things out of way there's a reason for
this this is done by people and if if
you do it often enough you will do it
yourself because you'll be a believer
because you'll realize that darn it if I
had written a little script if I'd taken
you know know five minutes and written a
little shell script to do that then I
would not have had that typo that cost
me three hours to go track down uh
closing thoughts on you and then we'll
wrap this one up yeah so I'd like to add
one additional thing to the idea of
stuff getting kicked down the road like
Pro you know um tasks taking more than
one
Sprint one thing that can occur and it
does occur a lot in software development
is someone comes up with an idea sales
talks to a customer and within the
course of the current development cycle
you tend to get what's called scope
creep you get new things added that are
not necessarily thought out and it can
cause things to really start going off
the rails which causes the backup if you
start encountering that if you can push
back and try to get that into the next
release cycle so you can finish the
current level of work sometimes you
can't but if you can will help keep a
divide between the different areas of
work being done uh otherwise SC Creek
really big problem could potentially
derail an application or it could really
push your deliverables off track the
other thing I'd like to touch on just
slightly so we talked about the idea of
projects you know those late nights and
having to be all hands- on Deb sometimes
that is the fault of the software
sometimes a bug gets found but sometimes
this could be something that is totally
unintentional and and kind of a side
effect of something else going on
somewhere else in the
company a real quick example of that is
years ago we both worked at a company uh
this was before Rob came on but we were
going through a major systems upgrade
behind the scenes and they had it all
ready to go all tested and they were
about to turn it on when we found out it
did not work with our current web
application software they forgot to test
it literally 10 days before they went
live because they had to go live for a
federal
requirement we had to completely
overhaul our application server install
a brand new updated server to work with
everything and literally we were working
almost 24 hours 10 for 10 days to make
this happen we were talking to support
in every time zone from Germany to Japan
to California I mean it happens don't
panic when that happens you're going to
have a lot of anxiety trust me but just
understand what the problem is make sure
you have the numbers of who you need to
talk to the support people and work
together you know basically it's not
necessarily one person's uh problem to
solve unless you're a one person shop
but it's the the help of the team it
takes a community to kind of get you
through this these kind of problems so
use that and don't you know don't fall
on your sword and be the only person
that oh my God I have to figure this out
work as a
team I think that's the probably The
Parting thought that I want to put into
this is that yes this sounds you know
we're painting not a very happy picture
but these are also the times that you
bond with your team these are the like
these are the Box hole moments and stuff
like that where you go through this
stuff and you will come out of it on the
other side I think a little closer
tighter um it is really a good team
building kind of experience so don't you
know don't freak out it happens life
continues you're going to have you will
sleep again you know stuff like that
unless it's a Death March and that's a
whole different problem we'll talk about
those another time because when we're
just want to have another cheery
discussion like this that being said if
you're feeling really cheery right now
and want to give us some feedback please
shoot us an email info developer.com you
can request things that you want us to
talk about you can give us feedback you
can trade War Stories whatever it is
we'll read it we may probably will
actually at some point refer to it on uh
on the YouTube channel or out on the
podcast you can also check us out on
develop ur.com you can enter information
in our forums there's a contact there's
a contact us form there you can send us
stuff on Twitter X you can leave us
comments here you can leave us comments
on YouTube you can check us out on
YouTube if you're not and if you're on
YouTube and you're then you can check us
out on our podcast all of that being
said we are not done I know that's a
shocker we're coming back we're going to
have more information more things to
discuss next time around so until the
next time go out there and have yourself
a great day a great week and we will
talk to you next time
[Music]