In this podcast, Krish discusses the process of building a new application, focusing on the approach of starting coding quickly rather than waiting for detailed requirements. Using the example of creating an application for a smoothie place, he contrasts traditional methods of gathering requirements with a more agile approach of making assumptions and starting development promptly. Krish emphasizes the importance of getting started, suggesting beginning with building the user interface without worrying about persistence or security. He highlights the value of even a simple initial accomplishment and suggests expanding on the application iteratively. Overall, Krish encourages listeners to start coding sooner rather than later to build momentum and make progress efficiently.
Summary
Introduction:
- Introduces the topic of building a new application.
Considering Different Approaches:
Discusses potential approaches for building an application, considering different contexts.
Uses the example of building an application for a smoothie place (Robeks).
Discusses traditional approach of gathering detailed requirements upfront.
Mentions assumptions and considerations when starting a project without concrete requirements.
Starting the Project:
Discusses the traditional approach of understanding requirements thoroughly before starting development.
Proposes an alternative approach of making assumptions and starting coding quickly.
Suggests starting with the persistence layer or making assumptions about the database structure.
Considers starting with building the user interface (UI) without worrying about persistence or security.
Discusses using existing frameworks or libraries for development.
Emphasizes the importance of getting started and building momentum.
Building the First Page:
Details the process of building the first page of the application.
Emphasizes starting with a simple page to display data (list of smoothies).
Discusses adding dependencies, setting up data, and rendering the initial page.
Highlights the value of even a simple initial accomplishment.
Mentions the possibility of expanding on the initial application in future podcasts.
Podcast
Check out on Spotify.
Transcript
0:01
Hey everyone, this is Krish.Hope you're doing well.Manage your projects on snowpal.com, be organized and be happy.Now, having said that, in this podcast I want to talk a little bit about building a new application and how you could go about doing that.
0:19
Or let's talk about a few different potential approaches, generally how people get started and explore the pros and cons of the different approaches and see which ones might make the most sense in a given context. So let's say you're working for a client and the clients asked you to build an application.
0:40
Are you doing it for your own?Your own company?Are you doing a project, just learning something new?Whatever might be the case, the ultimate objective here is for you to build something that's functional and you may or may not have concrete requirements that are written down someplace, right?
0:58
So let's make a few assumptions as we go with just my main interest here is to, you know, get you started if your intention is to just go with building something and not be stuck with a variety of items that you may or may not have the answers to when you get going.
1:15
So I was just thinking what example I could possibly take, just like a minute before I started recording the podcast.And you know, I'm hungry, so I just thought about food. So let's take that as an example.Let's say someone asks you to build an application for a restaurant or not a restaurant necessarily.
1:37
Let's say a smoothie place.I'm just going to take the one that we generally frequent. It's called Robeks. So let's say you own, you're a franchise, you own one or more Robeks, right?And then you want to build, build an application that that does a few things.
1:54
And let's figure out what those few things are as we go.Let's say you own more than one Robeks and you want to have an idea as to which products you know sell more so than others, what times of the day are more busier compared to the other compared to other times and and so on and so forth, right.
2:15
These are just random examples that I'm thinking of the top of my head.And obviously if in the real world scenario maybe that the corporate company has these tools already, so you wouldn't have to build it.But again, you get the point. It's just an example. So now if you have to do this and you have someone asks you to build an application to answer some or more of these questions, how could you possibly go about it?
2:37
One option, a more traditional approach, at least in the past, was, OK, let's understand all the requirements from top to bottom.How many Robeks do you own at this point?Do you expect to have, you know, own more of them in the near future?
2:54
Give me more details about each of those locations.How many customers do you generally have on, on, on Mondays versus Tuesdays versus Wednesdays?What products, what do you sell?What are the different kinds of kinds of smoothies that you sell at each of these Robeks locations?
3:13
So I could potentially, you know, if I were the developer and you were the client, I could ask all of these questions, right, and try to get answers to all these questions and then come up with the detailed requirements document.I use the Word documents document loosely there, but you have a way to jot down your requirements however you end up doing it, and there's a variety of ways you could do it.
3:37
Let's talk about it in a different podcast. So let's say you have all your requirements documented and then you start thinking about the design, and then you spend a decent chunk of time building the design and it probably is a month before you write this first line of code, right?
3:55
And again, there are different project management terminologies like waterfall and agile and all of that stuff, but I'm not a project manager, so I'm not going to use those terms because I might end up using them incorrectly.I do project management in the context of the more technical work that I do, right?
4:12
Anyway, so you could, I mean, that's how software was kind of built in the past, right?Pretty much. So you try to find out every the answers to all possible questions you had at that given point of time.And then you did all of the due diligence before you got started.
4:28
Really by writing that first line of code.I mean, things have changed quite a bit.But even today, there's many different ways you could go about writing that first line of code.Even if it's not one month down the road, if it's three weeks or two weeks or a week, there's still a variety of different approaches that are out there.
4:47
So let's talk about one that I prefer.And and maybe it's not just one, maybe it's a it's a few different approaches.I use them depending on the project, the size, the team and what not.But the but the gist of it is if I were given a requirement such as this, how would I go about doing that?
5:05
Yeah, it's it's good to spend a few hours, maybe a couple of hours, 2-3, whatever, half a day with the client just to understand what they do, what which business they are in, what they're trying, what what they have working at this point of time, what they're trying to accomplish in the near future and and the near to long term future, right.
5:24
Just quick discussions, just half a day or so. So now you get a good, you get a decent idea as to what your client's doing or what you want to be able to build, even if it's for yourself.After that, before we start worrying about how many locations, how what are the different kinds of smoothies, how many employees the Robeks might have, how many customers they generally entertain or serve during the course of any given day, how busy their weekends are and all of that stuff.
5:54
I think if the requirement is to build something related to Roebucks and customers and helping the owner understand what sells more than others and how to improve their business, I think you can make a reasonable number of assumptions.
6:10
Not execute those assumptions as code, but just make the assumptions, keep them at the back of your mind, and then start writing your code literally right so after the first half of the day.And we can take these numbers hours and days with a grain of salt.I'm just trying to make the impression that you want to write that first line of code as quickly as possible.
6:31
So now what you could.Let's say you more often than not you need a persistence layer. So you might say, OK, it probably is not a bad place to start.Design your database.Have your collections or documents or tables or fields depending on the type of database you use.
6:47
Get those items ironed out before you start thinking about your actual application.Which is all right, but that's just one way to go.The other option is, again, make more assumptions about your database, right?Let's not worry about persistence, Let's not worry about storing anything anywhere.
7:05
At this point, I just want to sort of feel these pages come to life.Let's say you're building, in this case, let's say it's not a mobile app.Let's say it's a web app because the Robax owner wants to do a lot of analytics and wants to understand they want to look at charts and graphs and all of that kind of stuff that needs a bit more real estate.
7:27
So let's say we are building a web app.Once you decide, you may have your frameworks of libraries of choice.If you do, sure.If not, you may want to spend a little bit of time so you know you're getting started using the most current and the most stable of platforms and technologies that's available out there today.
7:47
And maybe your your client already has a functioning platform, so maybe you don't have, you don't have to reinvent the wheel there. So if they're using React versus Dart versus Ionic or whatever, right.You just use that framework and you say, you know what, let me build this first page.
8:07
The page is not secure. It's a public page, It's not SSL, none of that stuff. It's just on your local dev, your machine, your sandbox dev sandbox. So you're going to build this first page that's just going to show a list of smoothies that Robek sells.
8:24
Again, there is no database.There is no other server but your machine.There is, you know, no security, no SSL, none of that stuff.You just want to go be able to build that simple first page.And a lot of times there are templates out there so you don't even have to build a lot of it yourselves.
8:42
You can piggyback on some samples that are out there on GitHub and or look, you know, just look up other examples and more often than not you're going to find one.Even if it's not close enough, it'll at least give you a starting point, like a scaffold. So you build that first page.Sorry.
8:58
You start building the first page.And what is the what is the end goal for that first page?It's going to show a list of smoothies.That's it.You can't make any edits, no CRUD operations. It's just going to be a GET. It's going to show you smoothies, and it's not going to show them in any fancy widgets or grids or any other UI components.
9:16
It's just going to display, say, 10 records, right?10 rows of smoothies.Now you might ask, what did I accomplish by doing then?Well, you did accomplish a little bit, even if not a whole lot.You first.You got started.
9:31
You got your feet wet.You have your basic dependencies.You know, even to get to this point you need to even if you have a scaffold you need to build.Either you clone an existing sample out there, or you start writing the first lines of code to add the dependencies.
9:49
Right?Whatever those two or three or four initial dependencies are, you edit to your pub spec or gem file or whatever, right?Package JSON.Depending on what which stack you're using to build this, you go add some of the dependencies and so your page comes up and the first accomplishment is actually a blank page, not even one that has a list of smoothies.
10:09
It is just simply a blank page and then you stab out your response. So let's say your exchange with your server is going to be in Jason and more likely it's going to be a Jason exchange, and you may not have decided whether it's a graph API or REST API or whatever, but doesn't matter.
10:27
You're going to get JSON, you're going to send and send JSON, get JSON back.Let's just create a data directory and stick a sample JSON.I'm going to create a file called smoothies dot JSON that has a list of an array, a Jason array which has five or ten elements, each of them 1010 elements in the array with with each element being a smoothie.
10:50
And then each of the smoothies might have three or four attributes. It has maybe an ID, a name and a description and a price probably right, that's good enough.Now we're going to have that first page read this static data, which is either it could be in in blueprint or Apri, or you can even create this directory and a file literally in in your code base for now.
11:14
And then you can just build this first page to show those smoothies.Now even though this didn't prove much right, it's a super simple page.Almost.Bottom line, you could even think useless, but it's not because it not helped.You get your feet wet, you've ironed out some of your dependencies and then you have an app to whatever level it is, right?
11:34
Sure, it doesn't have 99% of everything else that you need, or 99.9%, but it's got the .1 person, and getting that just immediately on day one, I was going to sort of help a whole lot. So I guess I may have rambled a tiny bit like I almost always do.
11:55
But hopefully you got the the crux of what I'm trying to say here.Don't spend too much time before you write that first line of code.And if I remember this when I do the next podcast, and I hope I do because sometimes I'm doing completely unrelated podcasts, I'll take this a bit further and see how we might we could expand on this initial simple one page render smoothies application.
12:20
I hope that helps a little bit.
Thank you.
Top comments (0)