Detailed Notes
Welcome to another captivating episode of "Building Better Developers." Join your hosts, Rob Broadhead and Michael Meloche, as they delve into the intricate world of software development and share their hard-earned wisdom from the frontlines. Today's topic is a familiar challenge that developers often face: the delicate balance between adhering strictly to software development requirements and unleashing one's creative prowess.
Read more: https://develpreneur.com/software-development-requirements-staying-true-to-specifications
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.
Transcript Text
[Music] and so I'll do this so that you can cut this real easy and we'll do a 3 two one and then hopefully you can Tech check that out as well so welcome back we are just cruising right along and thinking about our next episode uh one of the things we're doing is we're playing around with some actually utilizing you uh just behind the scenes stuff utilizing some Ai and other editing type tools to see if we can find ways to more easily and automatically edit the uh the cuts from episode toep episode and where we start and stop our uh our podcast which we've talked about that we had an episode a while back how you can use Visual and audio cues that are going to be things that are going to help you in that editing process but right now we're going to think about our uh we're going to do our brainstorming process and figure out what is our next topic that we want to cover for the podcast once again you can see that we spent a lot of time going into this behind the scenes beforehand we've really scripted this sucker out and you know we know exactly what we're going to say or not thoughts for this episode so the last one we kind of talked about you know the Don't Panic situations talked about communication last week we've got a little bit of Theos what was that have we touched on silos uh we probably have but we can definitely touch on silos what are you thinking uh I was thinking like communicate like interdepartmental Communications like we've talked about software working with our teams working with the customer but we haven't really talked about working with multiple teams within an organization oh yeah that becomes a that's an interesting like hand you like talking about like handoff points and stuff like that kind of um and kind of working with different departments like collabor collaboration with different departments and the customer like in some cases for example in my current position I don't ever see my end customer I don't know who they are what they are I have an idea what they do based on what our requirements are but we never see them so we're kind of writing in a vacuum and we have QA we have marketing people we have sales people but we're kind of heads down we have our product manager and product owner and that's it well those are yeah that's that's actually it's that's almost with blinders on that's actually like coding when you don't get the W you don't have it's just coding the requirements at that point it's a and that's where you just sort of that goes that really goes into I think what we touch on them regularly is sort of like the you know you're going to have to ask questions when you get requirements if a lot of s you got to you got to read through it think through it and then you got to make sure you're asking questions about it like okay like this is what the requirement says but what does that really mean as far as like you know what kind of what are the constraints you know and it's it's really walking through a requirement and how do I know what a requirement is how do I Define a requirement how do I vet or test a requirement and then how do I translate that into you it gets into the development side of okay how do we take that and and implement it and because our biggest problem is we literally have to write to the requirements like correct we can't add anything and if it's implied we have to go back yeah that's a um I think that's probably a good one is is we could talk about writing the requirements when it's writing to requirements and this actually this actually gets into um like fixed bid and other things like that is it's like okay what where do I stop what what makes this a requirement and and it does I think really gets into like you know you take it word for word um but I think that's a good one is is handling those situations so and if it's not all right we'll have a crappy episode but I I think we'll find a way to make it work hello and welcome back we are just cruising run along in season 21 I do believe it is of the building better developers developing or podcast we are into a season where we're this season we're really just going through some of the trials and tribulations that we have as developers myself I hit them on a regular basis my name is Rob Broadhead one of the founders of develop andur I also am a founder of RB Consulting and go out and do software development all the time and so that's where I run into some of these Road bumps and such one of which we're going to talk about today which we're going to get into working specifically towards a requirement like fulfilling to the letter in a sense a requirement but before I do that one of the requirements is that iow Michael to introduce himself on the other side so go ahead and do that hey everyone I'm Michael MOS I'm a co-founder of develop preneur and founder of Envision Q8 where we help small Healthcare clinicians and small businesses uh build software and test their and improve their software through testing so this is a I want to talk about this time is a actually is one of these things it could be a very big topic but we're going to narrow it down and the idea originally we talked about and those that are because we do have a YouTube channel you could watch us as well as listening to us uh those that were listening watching beforehand though that we we got into this a little bit because it started at building stuff in silos and this is you know when you're building software and you don't have access to the End customer where you're software is basically down to your writing code to requirements it's not really a developer side this is almost going backwards it's not better developers these are people that are just and sometimes you have to do this because sometimes it's a fixed bid project or there's certain priorities and things like that and maybe you don't know all of them but they've listed them out effectively in the requirements they've given those to you and said we need to do a b c d that's it that's this is the challenge is because we usually are going to look at AB c and d and we're going to have a vision and it's not going to be the same as what they have and as we get into it we're going to see because we're developers we're going to see where we could do this or we could do that or we could do this other thing one of the most frustrating customers I've ever had was one that did not want us to change the code other than exactly the minimal changes to the code to do that task and the code was atrocious and they knew it it was like there was all kinds of CRA it was like it was hard to read Because there'd be like there'd be two lines of code and then there'd be five blanks lined and then a line of code and then there a couple blank lines and then a line of code and then sometimes it'd be spread out and some it all be jammed up just visually it made you like your head spin a little bit and they knew this but they didn't want to change anything and you may be in those situations maybe you're like DOD or something like that where it's like you don't know why you're doing it all you know is that this is the requirement and so those are the situations I want to talk about today is when you have a requirement or you know a hard list of requirements like this is the task you're supposed to do this gets into something that's very near and dear to Michael's heart because he mentions it probably every episode is look at the requirement and then make sure you clearly understand it do not be afraid to Kickback questions what however you can do those to say okay you gave me these requirements but here's some things that I need to have clarification on you're not saying that their requirements are no good or that they can't be done or anything like that what you're trying to do is you're trying to make sure that you understand the scope and the context and then when you get and so that should give you the start is make sure you understand very clearly if you can don't be like sometimes the best way to do it is to essentially verbalize back whether it's through an email or whatever to say okay you sent me these requirements and so you basically respond back with the design or something along those lines that say okay this is what I'm going to build or this is what I'm going to code or this is what I'm going to create it's going to do this and this and this and it may be that that's there maybe that's you're just adding to that ticket because you're saying okay let's make sure that I know what the uh the criteria are to say that it's done what are the validation criteria to say that this works what are the things that this you know what are the various inputs and what are the acceptable outputs walk through that data this is where you have to get really detailed because what you don't want to do is anything that's beyond what's in that requirement because you don't know and I will tell a nice little story too this is a shared person we know you don't know what effect that's going to have on something else so if you go outside of the if you color outside of the lines in a situation like this it could be a problem now I'm going to give you an example that is more than you probably are going to get into in this kind of situation but an example of not of going outside the lines we had a situation uh somebody that we were working with a developer the the requirements were pretty simple it was we need to we need to give a response we need to have a popup I think it was a popup window or it was a you know message bar kind of thing that says that when you you know save something or edit something that you get a response back that says hey you know I saved it you know this has been saved this is this was a successful transaction that was essentially the the gist of it it's like hey on this application we've got five places that we do these actions we need to have some sort of we need to have a confirmation so the user knows that it you know that it occurred guy that did this developer was like young and go getet her and wanted to show stuff off so first off he turned it into a little popup window cool okay you want to do a pop window instead of a status bar that's all right that's fine that wasn't in the requirement that still works that shows them something now the problem is starting with just that window is that now that means somebody may have to click to continue on and maybe they don't want to do that so if you're thinking about that don't do it unless there's something implied and or ask a question and say hey I'm thinking about doing this with your original design say this is what I'm going to do let's make sure that this conforms to the requirements if it doesn't say give me a popup if it just says show us status then you just show us status on the screen in some way form or fashion don't add the popup error number one error number two is his popup was in text that was like little blinky lights that nobody likes Blinky lights they did in like 1970 when there was a first web page came out when Al Gore created the first web page since then nobody wants little blinking lights around their messages so that was also an error because it's like you can do it but that doesn't mean you should the other thing he did which is actually a really interesting little tweak that we need to consider along with the pop-up box is that he had it fade away after five seconds is it would flash the text up and it would fade away and everything would go away so if you turned away if you hit save and you turned away and you look back you may not see that message at all our boss read him the riot act over that stuff because he's like I don't like these I don't like this look and you can't do that because people aren't going to be able to see it and it it totally blindsided him because he was going into a meeting thinking he was goingon to get a big pat on the back and a I don't know Kudos or Rays or promoted to CEO or whatever it was he thought it was all good our boss did not ripped him a new one and it is because and it's his fault and it's it is his fault because he had requirements and decided to color out of the lines and that was not part of it now if you're a designer if you're something where they say hey go make this work we want you to build something that impresses us then you may do some of that but even then even if you're not in a silo think about what may impress those people or ask them about it or give them some options so that you're not putting something in front of them that they end up not liking because you don't want to spend a lot of time building something that isn't going to work or isn't going to fit the requirement ments so look at the requirements be clear and then if you have an itch to do anything that is not part of the requirement it's like it's it's like the old what would Jesus do it's like what would the requirement do look at the requirement and say does that thing that you're building does that exactly match the requirement and if not don't do it ask a question see if this is needed or or if you're trying to help them say would it be helpful if we can do that because sometimes you're going to clap back and say no sometimes they're going oh I didn't think about that yes let's adjust the requirement your thoughts on that while I close windows that are being rained in on yeah so the first thing that came to mind on that I I I know I keep bringing this up but it goes back to that um swinging roller coaster cartoon that's on the internet for software development where it the initial request from the user is they want a tree swing and it goes from every concept of wooden plank swing putting it on a tree cutting the tree in half building for a roller coaster not supporting it Etc requirements are important but the other thing that's interesting in this conversation is Rob mentioned is if you are doing this as a fixed bid or you're doing this as a contractor or you are working in a silo for an organization anything you do costs time which cost you money so if you have a requirement that really should take five minutes and you spend an hour because you do all this extra stuff that the customer didn't ask for one yes you might impress them but two you just did a whole bunch of work that you're not going to get paid for the other flip side of that is anything you work on make sure you understand what it is that you're trying to do as Rob mentioned we had this friend that did the little popup window think about the user experience as well as the requirements is what you're going to do going to impact the end you user in a positive way or in a way that meets the requirements because you could do something that is really cool really neat within the scope of the requirements but still not meet the need of the customer so I wantan to I do want to hit on that one thing that that Michael mentioned because it really is it goes back to these when we're not in uh as Silo when we get assignments part of the thing that we look at from the requirements is um which is very helpful for us as well feedback and estimate if they haven't given you an estimate then feed something back of hey this is going to take an hour two hours a day a week whatever it's going to be or look at and take into account what their estimate is if they give you something and they say okay here's your work for the week then you know that they're expecting it's going to take a week that can help you figure out how much you're supposed to add in even if it's not an as Silo and I have dealt with this a lot of times with people as a as a manager as well of developers is to say okay this is what you're going to do I'm expecting it back today or in an hour I don't expect I expect you get these 10 things done today so that should help somebody know or help you know if there's like you know it's like this is your daily to-do list if you're stuck on you if it's got five items and you're stuck on the first one for seven hours probably not going to get it all done unless those other things are super easy so one if there's something that seems like it's going to blow up that it's like that you're chasing it it's like this seems way more complicated than I thought it was don't be afraid to feed that back and say hey this is this is a concern this is not where it's supposed to go that's part of this part of why agile is what it is when you do a daily standup and say hey this was supposed to be you know two days of work roughly I'm into my my whole first day and I'm not even nowhere started on this things like that is feed that back because it may be that either you've misunderstood the requirement or the people that are creating requirement may not understand what that means and particularly with a customer this may be something like oh if it's going to take you know I thought it was just going to take you five minutes if it's not going to take you five minutes I don't need it there's you it allows people to properly prioritize and it helps you to think through like what is really expected out of this if if it's something where you've got like you know very strict requirements and it's it's you know something where it's like oh that's pin lines a code if I do it a certain way then it's like okay and you only have time to do those 10 lines of code then that's what you do now obvious yeah obvious well it's not obviously but it should be included that you're going to have you know you're going to do some testing and some validation and stuff like that as well so nothing gets done like that at least not completely done um but that is a that is a really important thing to think about is what is the the scope and the expectations of what you're building as well because you don't want to be in a situation where you run especially these days with the the mobile development kind of stuff we do the remote development that we do where we're out there somewhere we get some requirements if we go away for a week and come back and we're nowhere close to end but they thought we were done with those requirements four days ago then that's going to be a problem so we want to make sure that we're clear also on uh the scope and the level of effort that's going to be involved with what we do and with that also something we haven't really talked about here you know if you're in this Silo environment you might not be the only one the software you could be working on could have multiple different teams multiple different silos working on this application so your potentially your changes could impact someone else or someone else's changes could impact you so understanding the requirements and understanding how that interacts not necessarily full big picture but a bigger picture as the to the why we're doing this does make sense unfortunately in some situations you don't have the capability of asking that why you can only really get into the requirements as to all right what is within the scope of this ticket what am I doing you know why is this needed not necessarily why is this application needed but within the functionality that you're working on you need to forcefully not forcefully but you need to uh at least understand and be forthcoming with the person who's requesting the changes that could be the project owner that could be your boss you know it could be another developer it could be a bug ticket that was reported but make sure you understand what the issue is what the requirements are are there any screenshots are there any scripts to kind of lay out how to test this you know is this a user interaction is this a web page uh is there any diagrams to kind of help you understand how it's all put together and then from there then you can give an estimate now if you're new to this game you're going to be wrong a lot you're going to be behind the ball so make sure you give yourself time at least on the first few assignments to really understand what it is and how things work within the organization as you build up your skills you're going to be better at estimating those times but you know even us season developers you know we can miss something because we don't have a requirement this 1H hour change can now take us a week that because whoops we need this third party API or we need this integration piece oh that's not done yet well we can't move forward we can build something to you know to stub that but that still takes time and that was time that was not considered in the initial requirements and that's actually a good the working as a team is part of that as well is because sometimes you're going to be given something and there is an expectation of when it's going to be delivered and you may look at it and say Hey you know I'm going to deliver it a little late but I'm going to add so much extra stuff to it that it's going to be worth it you don't have the you may not have the ability to make that decision because what may happen is that your piece has to be done by that time because somebody else is waiting on it and so if you delay then it causes somebody else to be delayed and then somebody else to be delayed and you can throw a lot of stuff off schedule if you start you know sort of going off on your own so it's it really is this topic really does cover the it's almost like the reverse of building better developers it's it's being a better developer as a team player but it's really when you're in situations and we all will hit those sometimes where it's like we just need to be a coder yes we want to build all you know we want to have all this knowledge and experience around the solutions we build but sometimes it is it is not that we're building something better it's that they need us to build it faster because we can write that code quickly we can do it simply we can get there get in and get out and not be doling around and it's not that they need our ability to write the coolest most flowery awesome solution they need us to write one quick that works that we can verify and then move on and so understand the context of what you're doing and that will help keep you out of trouble final thoughts on this yeah the the biggest thing I kind of want to leave as a takeaway is as you're working your tickets or if you're working these contracts independently or fix bids on for customers take the take the requirements take the job take the ticket that you need to work on understand what it is you're being asked to do make sure you stay within the focus of those requirements and what the usit accepted criteria is don't go outside of the box in these situations don't add too many bells and whistles stay focused work on the task at hand and get the work done within the time frame and we're trying to get our work done within our time frame so we're going to try to we're going to wrap this one up and a respect your time as always you can shoot us questions at info developer.com you can check us out on Facebook you can check us out on LinkedIn you can check this out on YouTube you there's lots of places out there uh wherever you wherever you do podcasts we're out there and if not let us know they should already be there but if not we'll add ourselves to the stack uh as always looking for comments questions recommendations requests things like that anything any feedback we' love to have because this is as much for you as it is for us actually more for you than it is for us because we're just you know going through and and sort of venting a little bit at the end of the day and trying to help out some others so that we can essentially be a cautionary tale as others so that our mistakes are not repeated or at least you know that you're you know if you have already done those mistakes you're like hey I'm not the only one these guys do it as well and probably a lot of others that being said we'll let you get back to your day go out there and have yourself a great day a great week and we will talk to you next time bonus material anything that you got on this one I apologize because like parential rains came in by the time I I had a window all open because it was blowing before the storm and it was awesome by the time I got over there I had like two big hand towels it just got soaked because it had just water was just pouring in I'm like great that's what I needed right in the middle of the call so luckily you did a good job vamping through that part and for those you still listening you know always check your weather reports before doing podcast especially if you I had a house full of people I figured worst case they'll get it but it was like it came up like that and they're already scrambling all over and I'm hearing it come down and I'm looking over I'm seeing water almost like come sideways into the window I'm like all right I got to get this taken care of I had the flip side of that I had the lightning storm come in right before the call where I thought I was going to have power luckily I don't think I've seen the lightning we just get rain right here all right we digress back to the topic so final thought on this particularly so we've talked about in past podcast you know tools things like jir project management tools test management tools when you're dealing with something like this those kind of pop into my mind because if you're working to requirements if you're trying to get these tasks done you may not always have the big picture but you do have your ticket history you do have your code change history and you can look to see how things are being done the way they're being done and so as you're working new tickets or finding new bugs throughout the system you can kind of see how how things are done and also kind of organize your thoughts in a way to keep them concise so that you don't go outside the box too much so you're not adding too many extra bells and whistles to an application that doesn't need it and this actually you know we we we phrased this around uh fixed bed projects and silos and things like that but this is also something I've run into with customers from a Consulting point of view is that some sometimes they they're paying you to do that there is and even if it's an employee if you're like you know if you're a salaried employee you are paid to get things done and if we go too far a field then we're sometimes we're wasting that money we're wasting that time we're wasting what they're paying us to do um and it's like you I know that it's easy for developers to be like yeah this is sort of fun this is awesome I love this little rabbit hole but you sometimes have to rein yourself back in and say that hey this is this is costing them so either like you know if like if I'm going to punch off the clock and then do it okay fine but otherwise if I'm doing this because I'm sitting at my office at work and I've got an eight hour day and so I'm going to like do a couple of fun things and and part of that and add into it then you're not being the best H manager of the time and what these people are giving you so this also goes back and it it really comes full circle back to when you get requirement those you want those even in a a less structured a more open-ended U solution or application is to give feedback on that take a look at that get an idea of what really does besides the requirements what satisfies the goals there even if you do have somebody you're talking to make sure you're clear on what they're looking for and what level and things like that and don't be afraid to use like proof of Concepts or or MVPs or clickable demos or something to basically say okay this is what I'm expecting to build does this match your expectations now it may be that it's way over what they do and they want that they're like oh that's great I never thought about go for it but it may be that they said no you are you're giving me a a you know a Mercedes and I want the Yugo I want the Kia or whatever it is you they I want a ble I don't want that big you know honking thing that you're building so just because you can doesn't mean you need to and even if a customer comes to you and they say I have a million dollars to build this application do not build the application to the million dollars you build the application and the requirements and ideally you get it done in half a million dollars or something like that and they love you because you didn't just go through a ton of their money if you can do that that is part of being a building a being that better developer is delivering somebody not only more features than they expected but a better solution overall faster lower cost on time you Works maintainable scalable all of those bolds and and those kinds of things so that you are actually building better software for them give them a better deal and they will come back to you they will recommend you to others so don't be afraid of like oh I you know I gave up a half a million dollars on that project cuz I could have just you know gouged them for a million and they would have never blanked don't take that route take the high road take the the proper Road you'll be happier for it they'll be happier for it you will have a better career for it any other thoughts before we wrap this one up wow that's major bonus material there it kind of falls into the are you being busy for busy's sake or are you on task are you doing the job at hand because you know if you have a one ticket to work in a day you have eight hours in the day and it's a 5 minute ticket chances are you're probably going to take eight hours to get it done because you have to show that you have an eight hour day be smart be lethargic do the work in five minutes and then go talk to your boss and maybe do a PC maybe go do something fun or you know get approval to do something else cuz maybe there's something else uh another hot button ticket that needs to be worked but stay on task you know don't just be busy don't just fill time get the work done and keep moving things forward yeah it helps a lot to do that because it's going to if you're if you're pushing your boss if you're pulling for more work from them because you're getting stuff done faster than they expect it then yeah sometimes that can be a pain because then that just means they're going to start really piling stuff on but that means you're going to have a busy day you're going to be more productive and when you get to the end of the when you ever get to the review period then they're going to love you that's like they're going to be like you're the go-to person because you do that for them for now I think you guys can go to whoever your go-to person is my go-to is going to be like I think dinner and a drink or something like that so we're going to wrap this one up and uh maybe mop a little bit up here as well depending on how well I did during this this episode so thank you so much as always you know check for Stuff of the show notes leave us likes comments subscribe all of those fun things that people always ask for and we always forget to do and uh just keep an eye out because we're going to keep cranking these suckers out we will keep dropping them every Tuesdays and Thursdays both the podcast and the uh YouTube recordings go out we do occasionally throw some other stuff out on the site I mean the stuff all goes out developing n site but also there are the uh the blogs that occasionally get thrown out there we do have a newsletter feel free to subscribe to that I think I'm about a month behind but I will get the latest update on that out uh it's just been one of those months that being said once again you guys as well go out there and have a great day and we will check you guys out next time around [Music]
Transcript Segments
[Music]
and so I'll do this so that you can cut
this real easy
and we'll do a 3 two one and then
hopefully you can Tech check that out as
well so welcome back we are just
cruising right along and thinking about
our next episode uh one of the things
we're doing is we're playing around with
some actually utilizing you uh just
behind the scenes stuff utilizing some
Ai and other editing type tools to see
if we can find ways to more easily and
automatically edit the uh the cuts from
episode toep episode and where we start
and stop our uh our podcast which we've
talked about that we had an episode a
while back how you can use Visual and
audio cues that are going to be things
that are going to help you in that
editing process but right now we're
going to think about our uh we're going
to do our brainstorming process and
figure out what is our next topic that
we want to cover for the podcast once
again you can see that we spent a lot of
time going into this behind the scenes
beforehand we've really scripted this
sucker out and you know we know exactly
what we're going to say or
not thoughts for this episode so the
last one we kind of talked about you
know the Don't Panic
situations talked about communication
last week we've got a little bit of
Theos what was that have we touched on
silos
uh we probably have but we can
definitely touch on silos what are you
thinking uh I was thinking like
communicate like interdepartmental
Communications like we've talked about
software working with our teams working
with the customer but we haven't really
talked about working with multiple teams
within an
organization
oh yeah that becomes a that's an
interesting like hand you like talking
about like handoff points and stuff like
that kind of um and kind of working with
different departments like collabor
collaboration with different departments
and the customer like in some
cases for example in my current position
I don't ever see my end customer I don't
know who they are what they are I have
an idea what they do based on what our
requirements are but we never see them
so we're kind of writing in a
vacuum and we have QA we have marketing
people we have sales people but we're
kind of heads down we have our product
manager and product owner and that's
it well those are yeah that's that's
actually
it's that's almost with blinders on
that's actually like coding when you
don't get the W you don't have it's just
coding the requirements at that point
it's a and that's where you just sort
of that goes that really goes
into I think what we touch on them
regularly is sort of like the you know
you're going to have to ask questions
when you get requirements if a lot of s
you got to you got to read through it
think through it and then you got to
make sure you're asking questions about
it like okay like this is what the
requirement says but what does that
really mean as far as like you know what
kind of what are the constraints you
know and it's it's really walking
through a requirement and how do I know
what a requirement is how do I Define a
requirement how do I vet or test a
requirement and then how do I translate
that into you it gets into the
development side of okay how do we take
that and and implement it and because
our biggest problem is we literally have
to write to the requirements like
correct we can't add anything and if
it's implied we have to go
back yeah that's a
um I think that's probably a good one is
is we could talk about writing the
requirements when it's writing to
requirements and this actually this
actually gets
into um like fixed bid and other things
like that is it's like okay what where
do I stop what what makes this a
requirement and and it does I think
really gets into like you know you take
it word for word um but I think that's a
good one is is handling those situations
so and if it's not all right we'll have
a crappy episode but I I think we'll
find a way to make it work hello and
welcome back we are just cruising run
along in season 21 I do believe it is of
the building better developers
developing or podcast we are into a
season where we're this season we're
really just going through some of the
trials and tribulations that we have as
developers myself I hit them on a
regular basis my name is Rob Broadhead
one of the founders of develop andur I
also am a founder of RB Consulting and
go out and do software development all
the time and so that's where I run into
some of these Road bumps and such one of
which we're going to talk about today
which we're going to get into
working specifically towards a
requirement like fulfilling to the
letter in a sense a requirement but
before I do that one of the requirements
is that iow Michael to introduce himself
on the other side so go ahead and do
that hey everyone I'm Michael MOS I'm a
co-founder of develop preneur and
founder of Envision Q8 where we help
small Healthcare clinicians and small
businesses uh build software and test
their and improve their software through
testing so this is a I want to talk
about this time is a actually is one of
these things it could be a very big
topic but we're going to narrow it down
and the idea originally we talked about
and those that are because we do have a
YouTube channel you could watch us as
well as listening to us uh those that
were listening watching beforehand
though that we we got into this a little
bit because it started at building stuff
in silos and this is you know when
you're building software and you don't
have access to the End customer where
you're
software is basically down to your
writing code to requirements it's not
really a developer side this is almost
going backwards it's not better
developers these are people that are
just and sometimes you have to do this
because sometimes it's a fixed bid
project or there's certain priorities
and things like that and maybe you don't
know all of them but they've listed them
out effectively in the requirements
they've given those to you and said we
need to do a b c d that's it that's this
is the challenge is because we usually
are going to look at AB c and d and
we're going to have a vision and it's
not going to be the same as what they
have and as we get into it we're going
to see because we're developers we're
going to see where we could do this or
we could do that or we could do this
other thing one of the most frustrating
customers I've ever had was one that did
not want us to change the code other
than exactly the minimal changes to the
code to do that task and the code was
atrocious and they knew it it was like
there was all kinds of CRA it was like
it was hard to read Because there'd be
like there'd be two lines of code and
then there'd be five blanks lined and
then a line of code and then there a
couple blank lines and then a line of
code and then sometimes it'd be spread
out and some it all be jammed up just
visually it made you like your head spin
a little bit and they knew this but they
didn't want to change
anything and you may be in those
situations maybe you're like DOD or
something like that where it's like you
don't know why you're doing it all you
know is that this is the
requirement and so those are the
situations I want to talk about today is
when you have a requirement or you know
a hard list of requirements like this is
the task you're supposed to do this gets
into something that's very near and dear
to Michael's heart because he mentions
it probably every episode
is look at the requirement and then make
sure you clearly understand it do not be
afraid to Kickback questions what
however you can do those to say okay you
gave me these requirements but here's
some things that I need to have
clarification on you're not saying that
their requirements are no good or that
they can't be done or anything like that
what you're trying to do is you're
trying to make sure that you understand
the scope and the
context and then when you get and so
that should give you the start is make
sure you understand very clearly if you
can don't be like sometimes the best way
to do it is to essentially verbalize
back whether it's through an email or
whatever to say okay you sent me these
requirements and so you basically
respond back with the design or
something along those lines that say
okay this is what I'm going to build or
this is what I'm going to code or this
is what I'm going to create it's going
to do this and this and this and it may
be that that's there maybe that's you're
just adding to that ticket because
you're saying okay let's make sure that
I know what the uh the criteria are to
say that it's done what are the
validation criteria to say that this
works what are the things that this you
know what are the various inputs and
what are the acceptable outputs walk
through that data this is where you have
to get really
detailed because what you don't want to
do is anything that's beyond what's in
that requirement because you don't know
and I will tell a nice little story too
this is a shared person we know you
don't know what effect that's going to
have on something else so if you go
outside of the if you color outside of
the lines in a situation like this it
could be a problem
now I'm going to give you an example
that is more than you probably are going
to get into in this kind of situation
but an example of not of going outside
the lines we had a situation uh somebody
that we were working with a developer
the the requirements were pretty simple
it was we need to we need to give a
response we need to have a popup I think
it was a popup window or it was a you
know message bar kind of thing that says
that when you you know save something or
edit something that you get a response
back that says hey you know I saved it
you know this has been saved this is
this was a successful transaction that
was essentially the the gist of it it's
like hey on this application we've got
five places that we do these actions we
need to have some sort of we need to
have a confirmation so the user knows
that it you know that it
occurred guy that did this developer was
like young and go getet her and wanted
to show stuff off so first off he turned
it into a little popup window cool okay
you want to do a pop window instead of a
status bar that's all right that's fine
that wasn't in the requirement that
still works that shows them something
now the problem is starting with just
that window is that now that means
somebody may have to click to continue
on and maybe they don't want to do that
so if you're thinking about that don't
do it unless there's something implied
and or ask a question and say hey I'm
thinking about doing this with your
original design say this is what I'm
going to do let's make sure that this
conforms to the requirements if it
doesn't say give me a popup if it just
says show us status then you just show
us status on the screen in some way form
or fashion don't add the popup error
number one error number two is his popup
was in text that was like little blinky
lights that nobody likes Blinky lights
they did in like 1970 when there was a
first web page came out when Al Gore
created the first web page since then
nobody wants little blinking lights
around their
messages so that was also an error
because it's like you can do it but that
doesn't mean you should the other thing
he did which is actually a really
interesting little tweak that we need to
consider along with the pop-up box is
that he had it fade away after five
seconds is it would flash the text up
and it would fade away and everything
would go away so if you turned away if
you hit save and you turned away and you
look back you may not see that message
at
all our boss read him the riot act over
that stuff because he's like I don't
like these I don't like this look and
you can't do that because people aren't
going to be able to see it and it it
totally blindsided him because he was
going into a meeting thinking he was
goingon to get a big pat on the back and
a I don't know Kudos or Rays or promoted
to CEO or whatever it was he thought it
was all good our boss did not ripped him
a new one and it is because and it's his
fault and it's it is his fault because
he had requirements and decided to color
out of the lines and that was not part
of it now if you're a designer if you're
something where they say hey go make
this work we want you to build something
that impresses us then you may do some
of that but even then even if you're not
in a silo think about what may impress
those people or ask them about it or
give them some options so that you're
not putting something in front of them
that they end up not liking because you
don't want to spend a lot of time
building something that isn't going to
work or isn't going to fit the
requirement ments so look at the
requirements be clear and then if you
have an itch to do anything that is not
part of the requirement it's like it's
it's like the old what would Jesus do
it's like what would the requirement do
look at the requirement and say does
that thing that you're building does
that exactly match the requirement and
if not don't do it ask a question see if
this is needed or or if you're trying to
help them say would it be helpful if we
can do that because sometimes you're
going to clap back and say no sometimes
they're going oh I didn't think about
that yes let's adjust the requirement
your thoughts on that while I close
windows that are being rained in on yeah
so the first thing that came to mind on
that I I I know I keep bringing this up
but it goes back to that um swinging
roller coaster cartoon that's on the
internet for software development where
it the initial request from the user is
they want a tree swing and it goes from
every concept of wooden plank swing
putting it on a tree cutting the tree in
half building for a roller coaster not
supporting it
Etc requirements are important but the
other thing that's interesting in this
conversation is Rob mentioned is if you
are doing this as a fixed bid or you're
doing this as a contractor or you are
working in a silo for an
organization anything you do costs time
which cost you money so if you have a
requirement that really should take five
minutes and you spend an hour because
you do all this extra stuff that the
customer didn't ask for one yes you
might impress them but two you just did
a whole bunch of work that you're not
going to get paid for the other flip
side of that is anything you work on
make sure you understand what it is that
you're trying to do as Rob mentioned we
had this friend that did the little
popup
window think about the user experience
as well as the requirements is what
you're going to do going to impact the
end you user in a positive way or in a
way that meets the requirements because
you could do something that is really
cool really neat within the scope of the
requirements but still not meet the need
of the
customer so I wantan to I do want to hit
on that one thing that that Michael
mentioned because it really is it goes
back to these when we're not in uh as
Silo when we get
assignments part of the thing that we
look at from the requirements is um
which is very helpful for us as well
feedback and estimate if they haven't
given you an estimate then feed
something back of hey this is going to
take an hour two hours a day a week
whatever it's going to be or look at and
take into account what their estimate is
if they give you something and they say
okay here's your work for the week then
you know that they're expecting it's
going to take a week that can help you
figure out how much you're supposed to
add in even if it's not an as Silo and I
have dealt with this a lot of times with
people as a as a manager as well of
developers is to say okay this is what
you're going to do I'm expecting it back
today or in an hour I don't expect I
expect you get these 10 things done
today so that should help somebody know
or help you know if there's like you
know it's like this is your daily to-do
list if you're stuck on you if it's got
five items and you're stuck on the first
one for seven hours probably not going
to get it all done unless those other
things are super easy so one if there's
something that seems like it's going to
blow up that it's like that you're
chasing it it's like this seems way more
complicated than I thought it was don't
be afraid to feed that back and say hey
this is this is a concern this is not
where it's supposed to go that's part of
this part of why agile is what it is
when you do a daily standup and say hey
this was supposed to be you know two
days of work roughly I'm into my my
whole first day and I'm not even nowhere
started on this things like that is feed
that back because it may be that either
you've misunderstood the requirement or
the people that are creating requirement
may not understand what that means and
particularly with a customer this may be
something like oh if it's going to take
you know I thought it was just going to
take you five minutes if it's not going
to take you five minutes I don't need it
there's you it allows people to properly
prioritize and it helps you to think
through like what is really expected out
of this if if it's something where
you've got like you know very strict
requirements and it's it's you know
something where it's like oh that's pin
lines a code if I do it a certain way
then it's like okay and you only have
time to do those 10 lines of code then
that's what you do now obvious yeah
obvious well it's not obviously but it
should be included that you're going to
have you know you're going to do some
testing and some validation and stuff
like that as well so nothing gets done
like that at least not completely done
um but that is a that is a really
important thing to think about is what
is the
the scope and the expectations of what
you're building as well because you
don't want to be in a situation where
you run especially these days with the
the mobile development kind of stuff we
do the remote development that we do
where we're out there somewhere we get
some requirements if we go away for a
week and come back and we're nowhere
close to end but they thought we were
done with those requirements four days
ago then that's going to be a problem so
we want to make sure that we're clear
also on uh the scope and the level of
effort that's going to be involved with
what we do
and with that also something we haven't
really talked about here you know if
you're in this Silo environment you
might not be the only one the software
you could be working on could have
multiple different teams multiple
different silos working on this
application so your potentially your
changes could impact someone else or
someone else's changes could impact you
so understanding the requirements and
understanding how that interacts not
necessarily full big picture but a
bigger picture as the to the why we're
doing this does make sense unfortunately
in some situations you don't have the
capability of asking that why you can
only really get into the requirements as
to all right what is within the scope of
this ticket what am I doing you know why
is this needed not necessarily why is
this application needed but within the
functionality that you're working on you
need to forcefully not forcefully but
you need to uh at least understand and
be forthcoming with the person who's
requesting the changes that could be the
project owner that could be your boss
you know it could be another developer
it could be a bug ticket that was
reported but make sure you understand
what the issue is what the requirements
are are there any screenshots are there
any scripts to kind of lay out how to
test this you know is this a user
interaction is this a web page uh is
there any diagrams to kind of help you
understand how it's all put together and
then from there then you can give an
estimate now if you're new to this game
you're going to be wrong a lot you're
going to be behind the ball so make sure
you give yourself time at least on the
first few assignments to really
understand what it is and how things
work within the organization as you
build up your skills you're going to be
better at estimating those times but you
know even us season developers you know
we can miss something because we don't
have a requirement this 1H hour change
can now take us a week that because
whoops we need this third party API or
we need this integration piece oh that's
not done yet well we can't move forward
we can build something to you know to
stub that but that still takes time and
that was time that was not considered in
the initial requirements and that's
actually a good the working as a team is
part of that as well is because
sometimes you're going to be given
something and there is an expectation of
when it's going to be delivered and you
may look at it and say Hey you know I'm
going to deliver it a little late but
I'm going to add so much extra stuff to
it that it's going to be worth it you
don't have the you may not have the
ability to make that decision because
what may happen is that your piece has
to be done by that time because somebody
else is waiting on it and so if you
delay then it causes somebody else to be
delayed and then somebody else to be
delayed and you can throw a lot of stuff
off schedule if you start you know sort
of going off on your own so it's it
really is this topic really does cover
the it's almost like the reverse of
building better developers it's it's
being a better developer as a team
player but it's really when you're in
situations and we all will hit those
sometimes where it's like we just need
to be a coder yes we want to build all
you know we want to have all this
knowledge and experience around the
solutions we build but sometimes it is
it is not that we're building something
better it's that they need us to build
it faster because we can write that code
quickly we can do it simply we can get
there get in and get out and not be
doling around and it's not that they
need our ability to write the coolest
most flowery awesome solution they need
us to write one quick that works that we
can verify and then move on and so
understand the context of what you're
doing and that will help keep you out of
trouble final thoughts on
this yeah the the biggest thing I kind
of want to leave as a takeaway
is as you're working your tickets or if
you're working these contracts
independently or fix bids on for
customers take the take the requirements
take the job take the ticket that you
need to work on understand what it is
you're being asked to do make sure you
stay within the focus of those
requirements and what the usit accepted
criteria is don't go outside of the box
in these situations don't add too many
bells and whistles stay focused work on
the task at hand and get the work done
within the time
frame and we're trying to get our work
done within our time frame so we're
going to try to we're going to wrap this
one up and a respect your time as always
you can shoot us questions at info
developer.com you can check us out on
Facebook you can check us out on
LinkedIn you can check this out on
YouTube you there's lots of places out
there uh wherever you wherever you do
podcasts we're out there and if not let
us know they should already be there but
if not we'll add ourselves to the stack
uh as always looking for comments
questions recommendations requests
things like that anything any feedback
we' love to have because this is as much
for you as it is for us actually more
for you than it is for us because we're
just you know going through and and sort
of venting a little bit at the end of
the day and trying to help out some
others so that we can essentially be a
cautionary tale as others so that our
mistakes are not repeated or at least
you know that you're you know if you
have already done those mistakes you're
like hey I'm not the only one these guys
do it as well and probably a lot of
others that being said we'll let you get
back to your day go out there and have
yourself a great day a great week and we
will talk to you next
time bonus material anything that you
got on this one I apologize because like
parential rains came in by the time I I
had a window all open because it was
blowing before the storm and it was
awesome by the time I got over there I
had like two big hand towels it just got
soaked because it had just water was
just pouring in I'm like great that's
what I needed right in the middle of the
call so luckily you did a good job
vamping through that
part and for those you still listening
you know always check your weather
reports before doing
podcast especially if
you I had a house full of people I
figured worst case they'll get it but it
was like it came up like that and
they're already scrambling all over and
I'm hearing it come down and I'm looking
over I'm seeing water almost like come
sideways into the window I'm like all
right I got to get this taken care of I
had the flip side of that I had the
lightning storm come in right before the
call where I thought I was going to have
power luckily I don't think I've seen
the lightning we just get rain right
here all right we digress back to the
topic so final thought on this
particularly so we've talked about in
past podcast you know tools things like
jir project management tools test
management tools when you're dealing
with something like this those kind of
pop into my mind because if you're
working to requirements if you're trying
to get these tasks
done you may not always have the big
picture but you do have your ticket
history you do have your code change
history and you can look to see how
things are being done the way they're
being
done and so as you're working new
tickets or finding new bugs throughout
the system you can kind of see how how
things are done and also kind of
organize your thoughts in a way to keep
them concise so that you don't go
outside the box too much so you're not
adding too many extra bells and whistles
to an application that doesn't need it
and this actually you know we
we we phrased this
around uh fixed bed projects and silos
and things like that but this is also
something I've run into with customers
from a Consulting point of view is that
some sometimes they they're paying you
to do that there is and even if it's an
employee if you're like you know if
you're a salaried employee you are paid
to get things done and if we go too far
a field then we're sometimes we're
wasting that money we're wasting that
time we're wasting what they're paying
us to do um and it's like you I know
that it's easy for developers to be like
yeah this is sort of fun this is awesome
I love this little rabbit hole but you
sometimes have to rein yourself back in
and say that hey this is this is costing
them so either like you know if like if
I'm going to punch off the clock and
then do it okay fine but otherwise if
I'm doing this because I'm sitting at my
office at work and I've got an eight
hour day and so I'm going to like do a
couple of fun things and and part of
that and add into it
then you're not being the best H manager
of the time and what these people are
giving you so this also goes back and it
it really comes full circle back to when
you get requirement
those you want those even in a a less
structured a more
open-ended U solution or application is
to give feedback on that take a look at
that get an idea of what really does
besides the requirements what satisfies
the goals there even if you do have
somebody you're talking to make sure
you're clear on what they're looking for
and what level and things like that and
don't be afraid to use like proof of
Concepts or or MVPs or clickable demos
or something to basically say okay this
is what I'm expecting to build does this
match your expectations now it may be
that it's way over what they do and they
want that they're like oh that's great I
never thought about go for it but it may
be that they said no you are you're
giving me a a you know a Mercedes and I
want the Yugo I want the Kia or whatever
it is you they I want a ble I don't want
that big you know honking thing that
you're building so just because you can
doesn't mean you need to and even if a
customer comes to you and they
say I have a million dollars to build
this application do not build the
application to the million dollars you
build the application and the
requirements and ideally you get it done
in half a million dollars or something
like that and they love you because you
didn't just go through a ton of their
money if you can do that that is part of
being a building a being that better
developer is delivering somebody not
only more features than they expected
but a better solution overall faster
lower cost on time you Works
maintainable scalable all of those bolds
and and those kinds of things so that
you are actually building better
software for them give them a better
deal and they will come back to you they
will recommend you to others so don't be
afraid of like oh I you know I gave up a
half a million dollars on that project
cuz I could have just you know gouged
them for a million and they would have
never blanked don't take that route take
the high road take the the proper Road
you'll be happier for it they'll be
happier for it you will have a better
career for
it any other thoughts before we wrap
this one up wow that's major bonus
material there it kind of falls into the
are you being busy for busy's sake or
are you on task are you doing the job at
hand because you know if you have a one
ticket to work in a day you have eight
hours in the day and it's a 5 minute
ticket chances are you're probably going
to take eight hours to get it done
because you have to show that you have
an eight hour day be smart be lethargic
do the work in five minutes and then go
talk to your boss and maybe do a PC
maybe go do something fun or you know
get approval to do something else cuz
maybe there's something else uh another
hot button ticket that needs to be
worked but stay on task you know don't
just be busy don't just fill time get
the work done and keep moving things
forward yeah it helps a lot to do that
because it's going to if you're if
you're pushing your boss if you're
pulling for more work from them because
you're getting stuff done faster than
they expect it then yeah sometimes that
can be a pain because then that just
means they're going to start really
piling stuff on but that means you're
going to have a busy day you're going to
be more productive and when you get to
the end of the when you ever get to the
review period then they're going to love
you that's like they're going to be like
you're the go-to person because you do
that for
them for now I think you guys can go to
whoever your go-to person is my go-to is
going to be like I think dinner and a
drink or something like that so we're
going to wrap this one up and uh maybe
mop a little bit up here as well
depending on how well I did during this
this episode so thank you so much as
always you know check for Stuff of the
show notes leave us likes comments
subscribe all of those fun things that
people always ask for and we always
forget to do and uh just keep an eye out
because we're going to keep cranking
these suckers out we will keep dropping
them every Tuesdays and Thursdays both
the podcast and the uh YouTube
recordings go out we do occasionally
throw some other stuff out on the site I
mean the stuff all goes out developing n
site but also there are
the uh the blogs that occasionally get
thrown out there we do have a newsletter
feel free to subscribe to that I think
I'm about a month behind but I will get
the latest update on that out uh it's
just been one of those months that being
said once again you guys as well go out
there and have a great day and we will
check you guys out next time around
[Music]