Up next in 10
Keynote:7 Important Requirements for Any Successful Project || Code Quality & Performance Conference
5K views
Nov 9, 2023
I have said to engineers until I am blue in the face that management, for the most part, does not care about code quality or code/ application performance. They just want to “ship it” and get their bonuses! They do not care about unit testing and so much more, so it is up to you to push it for your team. But you, being the developer, will be left holding the bag if something goes wrong, not management that could lead to you losing your job. Even worse, when major changes must be made that causes you to a lot of re-writing of the code, management will get upset that it is taking so long. Therefore, proper architecture standards are so important. I will discuss what every app that goes into production must at a minimum have: 1. Architecture 2. Coding Standards 3. Unit Testing and More Unit Testing 4. Continuous Integration 5. Application Testing 6. Proper Environments 7. Memory Profiling These 7 subjects are key to launching a new app or system that customers will love and keep using! Conference Website: https://globaltechconferences.com/event/code-quality-performance-virtual-conference-2021/ C# Corner - Community of Software and Data Developers: https://www.c-sharpcorner.com C# Live - Dev Streaming Destination: https://csharp.live #Codequality #Successful #Projects #virtualconference #Application
View Video Transcript
0:00
All right. So, you know, I kind of wanted to wrap up the conference with something that I want to make sure everybody knows
0:10
And to me, these are the seven. There's lots of important things to make a successful project
0:15
But these are seven things that, you know, I think are important for every single project
0:20
I don't care what kind of project it is, whether it's a big internal application, small internal application, you know, a public application
0:28
all these things need to happen. They might change a little bit, but basically you need all these
0:35
things. And so that's what I wanted to talk about for my keynote. And it just so happens that these
0:40
things, most everything in my talk has been talked about already at the conference, which is great
0:45
I'm glad I picked this subject. So those of you who don't know me, I'm David McCarter. I'm a
0:56
Microsoft C Sharp Corner MVP, award-winning developer, architect, consultant, blah, blah, blah
1:01
I love playing music, as you all know, if you've been following me. There's my email address, Twitter handle, and LinkedIn
1:09
And so please contact me. Let me know not only if you need some help or you like the conference or your company needs me
1:18
because I'm looking for a new contract or a full-time gig right now. So please contact me
1:24
I don't get enough contact. This is what I'm trying to say
1:30
All right. So after I got most of this keynote done, I figured that, you know, everything I'm saying here
1:39
I hope you developers out there know this. So I decided to put the last line in there going
1:46
you know, this keynote is really for management because I don't know about, you know
1:51
other developers out there, But management is a big roadblock to me in most cases to get things done correctly and with quality and with performance, really, but mostly the quality
2:03
Because management, you know, I've said this until I'm blue in the face. Management really doesn't care about quality
2:10
All they care about is shipping features because that's what makes money. Who cares about quality
2:14
We do because we're the ones that are going to have to deal with it. So do you want to deal with bugs all the time or do you want to deal with no bugs and do features
2:22
I think the answer is pretty obvious, right? So make sure you download this keynote
2:28
and send it to all of your managers and project managers because they need this
2:33
because I don't know how to get it through their heads. So this is what the keynote's all about
2:38
But if you don't know any of these things, then I hope you're gonna learn something too
2:43
So, and this has kind of been said during the conference already
2:46
but how many times have you heard this? Our software features zero errors and zero warnings
2:52
Never. I've never seen a marketing ad that said that, right? Because like I said, nobody cares about that
2:57
All they care about is the selling features so they can make money, right
3:03
And they don't go around saying this because most companies can't say this
3:08
If you ask me, well, at least most companies I go to can never say this when they bring me in
3:14
The whole purpose a lot of companies bring me in is to fix this. And so I see a lot of bad code these days. And it's quite frightening, if you ask me. So never, you never hear anybody say this, right? So this is what I'm going to try to wrap this conference up is, is, you know, talking about these things that every successful project needs to have
3:38
And, you know, I've done everything in this talk. And the reason I have had six very successful projects is because I do these things
3:46
I've been doing most of these things my entire career, if not all of it
3:51
And so, like I said, things change as, you know, software development changes
3:55
But I've been doing pretty much all this my entire career. And I can't stress how important these things are
4:02
All right. So the first thing I want to talk about is architecture, because, you know, I think I've already said this during the conference
4:12
This is so lacking these days from most teams I go in and work at
4:17
It's like pulling teeth to get anybody to do architecture or do any kind of documentation these days
4:22
I don't know what happened. You know, like I said, I kind of blame some of it on agile, but it's super important
4:30
You know, so so all of you developers out there, you know, if you think this or your manager tells you to just sit down and start coding
4:41
Stop. Tell them no. You know, we need to stop. You need to architect it. We need to document it
4:50
Because a lot of those reasons have already been talked about during this conference is why this is super, super important
4:57
And, you know, I've spent months just architecting and documenting data objects
5:06
Right. It's I spend a lot of time doing this. And, you know, I've said this a lot. You might have heard this in this world
5:14
But if you spend most of your day coding, you are doing it wrong. You should not be spending most of your day coding
5:20
Most of your day should be doing other things like architecture, yzing, testing
5:26
you know, coding should be the least part of your job, really. I know this sounds weird, but that's definitely true
5:36
So you must, must architect any and document any project from the get-go or feature
5:44
Even if you're adding a feature to an existing project, you need to architect it and document it
5:50
I can't stress this enough. because most of my, I've already said this
5:56
most of my successful projects were all due to doing this properly
6:01
And everyone that's been successful has done this, you know, to some degree or another
6:08
And so, you know, what do I mean by properly? Well, properly to me, part of that means
6:15
meet with the users and understand their needs, right? I say this because I haven't heard a lot of this, but I'm one of the developers that want to talk to the users, right
6:28
I've left companies because they wouldn't let me talk to the users
6:32
Because if I don't know the user's needs, I can't improve whatever I'm trying to improve for them
6:39
And hearing it second or third party is not the same as sitting down, spending a whole day with the users
6:46
I've got many stories about this. But I've spent days with users just watching what they're doing and just understanding their current workflow or whatever they're doing
6:58
Because my job, my job for most of my career is to make somebody's workflow or life better
7:05
Right. And I can't do that unless I talk to them and see what they're doing now so I can improve that
7:12
This is so important. And like I said, I've left companies because I've asked them
7:18
please send me a day with the actual people using the product
7:21
And they refused. And I said, see you later. I find another company who will let me do what I want So you must meet with them right And then you must architect and document the project I can stress documentation enough And I really really frustrated that you know I see so little documentation these days and even less of architecture
7:43
So all the time you spend with architecture and documentation, which will increase, you know, the time in the beginning of the project
7:53
but you will save immense amount of time and money later in the project
7:59
Right. At the last team I worked on, you know, they worked on a project that I architected
8:05
I coded most of it. And one of the other more junior people in the team, you know
8:10
after we had to make some, you know, changes, improvements to it, you know, she came back to me and said
8:16
oh, my gosh, Dave, it is so easy to make changes in this code base. I go, yes
8:23
that's why I do this. I've succeeded. If it's easy to make changes and it's easy for a junior
8:29
person to understand, I've succeeded. But this all starts with architecture. And then once you come up with the architecture, go back and talk to the users about the solution
8:42
that you came up with and see if it's going to gel with their team or their company. Because
8:48
You know, the one thing I love to do is whenever I go to a doctor's or dentist appointment and they always use their software to put in your information and look at your records and things like that
9:00
Every single doctor and nurse I see do that. I ask them, so how do you like this
9:04
And they all hate it. None of them like the software. And I go, yep, that's because the people writing the software haven't come to talk to you
9:13
And so they don't know what they're doing. I'm a software engineer. I don't know how medical people do their work, right
9:19
So for me, writing software for them is kind of silly unless I understand their needs
9:25
and work with them on improving it, right? I'm gonna check the private chat real quick
9:36
So, you know, one of the most successful projects I've worked on, unfortunately, was like 20 years ago
9:42
So, but it was actually for, I was part of the original development department for proflowers.com
9:49
And, you know, I'm not going to go into the long story
9:53
I've written about it already, but basically, you know, the system that architected and wrote most of it for them ended up being patented
10:03
So now I'm a patented inventor now. And it's because of what I wrote. You can go Google me and look up the invention
10:09
But I invented that along with my CTO and one other guy that helped with coding
10:16
But I am so proud of this project because not only did I become a patent inventor, which is cool, but it doesn't make me any money
10:27
I learned a lot from this process. But the reason I call it successful is the users loved it
10:35
Right. And even users that never used a computer before could use my application and users that don't speak English could use my application
10:45
That's because if if I make the users happy, I've succeeded. Right. That's why I'm here. Right
10:53
So so this is my great. I have other examples, but this is the greatest one because it's patented
11:00
Sorry, I moved off of PowerPoint. So good architecture equals long-living projects
11:10
You know, projects last a long time sometimes. I mean, there's projects written, you know, 10, 15, 20 years ago that's still running, right
11:17
So it creates long-living projects. I rarely know any team that writes a project that's only going to be around three months, right
11:26
So you want them long-living, and architects will give you that. But the best thing is architecture will allow you to make changes easily
11:34
Good architecture will. Less bugs and other issues, right? Who likes working on bugs
11:40
Not a single person, right? And that's why a lot of developers leave after the first release of something
11:46
because then it's just bug fixing all the time. And that's not any fun. You know, I don't like doing bugs
11:52
I like creating features. And I like creating things out of nothing, right
11:57
That's what I love. I don't like fixing bugs. And you create projects other people talk about
12:05
like my patent invention. You want people to talk about your project
12:10
and how you came up with it or how you architected or how your team did flow like what he was talking about
12:16
You want people to talk about these kind of successes. And then you can, in the case of me
12:23
I turn those into talks. I turn them into articles. I put that information into my book
12:32
And so, yeah, everything. And in fact, doing this will save money in the long run
12:38
Unfortunately, too many companies in the bean counters, the accountants, don't see this
12:45
They don't see the long-term cost. They only see the immediate cost
12:49
That's a huge problem. and most companies, especially I said earlier, the bigger the company, the worse this is
12:57
And so this will actually save money. I guarantee it. Guarantee it. Otherwise
13:03
I'll work for you for free. I should have said that. It makes changes easier. Changes must be
13:12
easy. One of the last meetings I had with vice presidents and stuff at one company, I told them
13:20
And look, you know, until you break down and do X, Y, and Z, what you're asking is either
13:25
A, impossible, or B, will take so long, our competitor is going to beat us
13:31
And guess what happened? Both those things. And the product is not doing well anymore
13:36
So you must be able to make changes easily, including swapping databases, right
13:41
I know that sounds crazy, but you should be able to swap it out pretty easily
13:46
It will make you happy. You know, like what he was talking, when you're all in the zone, you're all working together, you all create something from nothing that the users love
13:55
That's the best feeling to me. You know, it's not the money. It's not the money
13:59
It's that feeling. And you will learn and keep your job. You know, all these things, whether, you know, it's good or bad, you learn from them, hopefully
14:12
And, you know, good architecture, you will learn. Right. And the more you learn up front will save you a lot later
14:18
And most important of all of architecture, this is going to create happy users
14:25
Happy users equal satisfaction to me. But in a lot of cases, it means you get to keep your job
14:33
Or maybe you get a big base or maybe you get a big bonus, right? Your users are happy
14:39
It trickles down, right? Otherwise, you're going to be left with users like this
14:46
Like all the HBO Max users from last night, right? That are all tweeting about the mistake that HBO Max did
14:53
with 44 million customers yesterday You know it pretty crazy And this is usually the way I feel when I use apps these days And the reason I talk about this so much and with so much passion is because I hate feeling
15:08
like this. I want to feel happy. And unfortunately, most apps I use make me feel like this
15:14
And so I want to improve it. And this is my way of improving it. All right. So let's move off of architecture. And now we're going to go to coding standards
15:24
near and dear to my heart, of course. Very important for the developers on your project
15:30
And we're going to be talking about that. So why are standards needed
15:34
You know, when I do this talk in person, I ask the audience, you know
15:38
why, if you use coding standards, you know, why do you do that
15:42
And here's some of the reasons. Every programmer on the same page, right
15:48
One of the speakers, I don't know if it was Woody or Jason, was talking about onboarding, you know, new coders
15:54
Right. One company I worked at, you know, it would take six months before new coders would
16:01
Kind of understand, you know, the what what the project was, what the product was, that's way too long
16:08
So if you use common standards that are out, you know, common standards that are in my book
16:14
Right. It'll be a lot easier for your programmers to understand it and read it and know exactly what's happening
16:22
right if we all use our own way of coding and standards it just becomes a huge mess and it's
16:29
unworkable and usually we have to spend a lot of time rewriting it so we don't want to do that
16:33
easier to read and understand code very very important code needs to be readable right because
16:39
you know the more you stare at it trying to figure out what is wrong with it so you can fix a bug
16:44
the more money you waste and so it must be easier to read must be understandable so stop using really
16:51
short variable names and parameter names. We don't need to do that anymore. It's not the 90s
16:57
You know, so make sure everything is readable in your code. Don't make, you know, big, long method
17:04
names, but, you know, concise and to the point. Code should be self-documenting, actually, in most
17:11
case. Easy to maintain code. You know, I always say, you know, how many times, you know, you've
17:17
written a code, you've, you know, you've, you've put it out to the public and never touched again
17:22
Yeah. Zero. Right. So you have to make sure you use standards to make it very, very easy to
17:29
maintain code. Because like I said, maintaining code, fixing bugs, all this is a drain on resources
17:35
and money, and we need to make that easier. So that's where coding standards can help. And in
17:40
the end, if you follow everything that, you know, coding standards, including, you know, of course
17:45
what's in my book, you're going to end up with stable, reliable code, right
17:49
That's what we want. We don't want bugs, right? We don't want, you know, the bugs like we've been, you know, experiencing here in the stream
17:56
yard today, right? So I guarantee you, coding standards will produce this for you
18:05
So I know I've plugged my book. You know, this is not the reason I'm doing this, you know, this section
18:10
I'm doing this section because it's super, super important. So, you know, if you don't have coding standards at work, please go pick up a copy of my book and create your own standards
18:21
Also, you know, you can pick up my code and app performance book, too, which has got all the performance stuff in it
18:28
And like I said, because you need to have a standard, right
18:32
It needs to be written. It needs to be documented in a single place and easier for developers to get to
18:39
um most companies 99 of the companies i go to have no standards none at all right it's whatever
18:48
you want to do and that's just crazy and um and it's even more important to have standards
18:54
if you use contractors right because contractors like me are there for a short time so they're
19:00
even worse at standards because they can yeah well i'm going to be gone in six months who cares
19:04
right um but it's super super important when you have contractors you know in my last company
19:11
everybody got a copy of my book other companies i've worked at every developer in the company
19:15
got a copy of my book and um because we all need to be on the same page right when we're writing
19:22
code and um and after selecting a standard like i said i i already said this you know make it easy
19:31
available to each programmer, right? It should be right. This book should be right next to your desk, unless you're me, because I wrote it
19:39
Or whatever standard you have, you know, it needs to be, you need to have it all the time
19:44
So you make sure you're not doing anything the wrong way. And on top of that, you need to enforce it either by doing code reviews, pair programming
19:55
and you can enforce it in the build process, right? Jason was showing a lot of the yzer stuff
20:01
You know, there's other ways you can check your code during the build process. But if you're not checking your code for standards during the build, you need to stop and start doing it
20:10
Right. Because how do you know the, you know, the code is correct if you don't check it during build
20:14
Right. Code, you know, code reviews and pair programming will catch most of it, but not all of it
20:22
But if you include it in the build process, it will catch all of it and don't release the code until it meets the standards
20:28
and make the developer go back. I've done this. I've even done this with the team in the Ukraine
20:32
I said, nope, not accepting this code until it passes, you know
20:36
the coding standards testing and everything. So my big tip for this section is
20:44
only change your standards on purpose. And if you do change them, document them
20:50
and then teach that to the rest of the team. You just can't, you know, tell the team
20:55
yeah, go read it as your leisure. No, you need to talk about it in a meeting or in a brown bag meeting, a brown bag lunch or something like that
21:04
You need to get the information out to all the developers, of course, depending on how large your team is, of course, or how large your department is
21:14
All right. So that's coding standards. I don't know if anybody's still watching
21:22
I don't see any comments. So unit testing and more unit testing
21:27
I can't stress unit testing enough, right? Because this is our first line of defense, basically, on fixing bugs that we've written
21:35
Or possible bugs, right? So the 100% of the projects I work on do not even come close to 75% code coverage
21:47
And, you know, the reason I bring up 75% code coverage is because when I was working
21:52
with the PM at Microsoft for two years. In Telecode, which Jason talked about
22:00
why that isn't in .NET Core and .NET 5 is beyond me. I know they are supposedly working on it
22:06
but I don't know what the heck is going on, but it's completely frustrating
22:10
that they haven't made this available. The Visual Studio team hasn't made this available
22:14
in .NET Core and .NET 5. But when I was working with the PM
22:19
that's what he said. that 75 code coverage is like the minimum goal you should go for right Anything public should be 100 of any public method should be covered right The private methods hopefully are being covered by the public methods but 100 of the public methods need to be
22:38
covered or don't release it or you have problems, you know? And that's why I'm very becoming very
22:46
very stringent on the code I release in my open source projects that anything new has to have a
22:51
unit test. And we're going back. You know, one of my friends is helping. We're going back and
22:56
writing unit tests for the older stuff. Cyclomatic complexity. I don't have enough time to get into
23:03
this because I can talk about this for half an hour. But if you have something like code rust
23:08
you can set it up to tell you while you're writing your code, the cyclomatic complexity of that
23:13
method, right? And if you don't know what cyclomatic complexity is, please go look it up
23:20
because it's super important because what that number means is the minimum
23:24
to me, what the cyclomatic complexity number means is the minimum number of unit tests
23:30
I need to write for that single method, right? And this is why I love IntelliTest
23:35
because it will basically write the scaffolding for you because it tries to break your code
23:41
And Jason showed that. And so this is the minimum number, right
23:46
So if your method has a cyclomatic complexity, one single method of 25, that means you need 25 unit tests, one method, right? How many
23:57
I've yet to see a method have 25 unit tests. I just don't see it because at least in .NET Core
24:06
and .NET 5, there's no easy way to do that. And so we write what we think we know, you know
24:12
maybe we use the new testing stuff in Visual Studio, it'll tell us, but we really need the
24:17
you know, the intelligence has to help us with this. So, for example, one project I worked on a
24:22
while ago, a single class or a recent project I worked on, a single class in this project had a
24:30
cyclomatic complex. No, I'm sorry. I'm getting mixed up. This project had a total, this project
24:36
had a cyclomatic complexity of 20,675. Sorry. I'm sorry. I'm laughing. I'm getting punch drunk
24:46
I've been up so long, but only had 249 unit tests. I'm sorry, I'm laughing
24:53
This is just unacceptable, right? So that's the number. If you see 20,000, that means you need 20,000 unit tests
25:02
And I've never seen anything have 20,000 unit tests. So you need to pay attention to your cyclomatic complexity
25:09
and make sure everything's covered with unit tests. You know, one project I've worked on about 10 years ago
25:16
when I, you know, we had over a million lines of code. And when I started the company, I had zero
25:22
unit tests. When I left the company four and a half years later, I had zero unit tests because
25:28
you know, they would never give us the time to do unit testing because they didn't see the value
25:32
My boss, who actually took one of my classes at the university here, actually said
25:36
and it upset me because he has taken my classes before I started working there
25:42
When I asked this, one of the first meetings at this company, I said
25:46
why don't we have any unit tests? And my boss said, well, it's okay
25:53
We'll just let QA find it. Oh, I couldn't believe it. I wanted to slap him upside the head
26:00
I'd be fired right away if I did, but I can't believe that comment
26:04
And so four and a half years later, no unit tests. so another company i worked at you know a couple days after i started
26:14
this was a couple years ago they literally came up to me and said and there was we had a very small
26:21
team there was two developers and two managers that's it right and one of the managers came up
26:27
to me because we all worked in the same office in the same office and he came up to me and said
26:32
Dave, we're going to give you admin access to AWS so you can push code into production
26:40
And I said, how many unit tests do you have? They said zero
26:45
I said, nope. Don't give me access. I don't want access, you know, because I don't want to be responsible for pushing code that hasn't been tested
26:58
Right. And so I said, nope. So the whole time I worked there, which turned out to be not very long, I didn't have access because I refused to do it
27:07
I let this, you know, if the managers want to take, you know, responsibility for, you know, testing, you know, pushing code that has been not been tested, go for it
27:16
But I'm not going to do it. So now one of the things I always do based on some companies I've worked at, because a lot of companies won't give you the time to do unit testing, documentation, things like that
27:28
you know what? I just don't tell them anymore. I just roll that into my estimates. And that's
27:35
the estimate. And I've worked at companies and they said, Dave, why are your estimates so much
27:41
longer than everybody else's? I said, because of this. I roll in unit testing and documentation
27:48
and that's why my estimates are longer. Deal with it. So, and unit test must also include tests for encapsulation
28:01
This is what IntelliTest did. You must test encapsulation 100%. I've said many, many times before that I rarely see code that does even encapsulation correctly
28:14
And if I see code that doesn't do encapsulation correctly, then I have little hope they're doing inheritance correctly
28:20
And I have zero hope they're doing polymorphism correctly. So we got to get encapsulation right
28:27
And, you know, I've said in conferences before that, if every developer out there did proper encapsulation
28:33
I would stop speaking, I promise. So that hasn't happened. So I'm still speaking
28:40
Test business logic. Like Jason said, not only do you have to test 100% of the encapsulation
28:46
but you need to also roll in your business logic testing too
28:51
And you must use random data as input. But, you know, too many people, you know, test data with known values that they know work
28:59
Right. Wrong. You don't do that because that will cause problems. I guarantee it. And that's actually why, you know, I created an open source project of the NuGet package that you can go see that it does this
29:13
The whole purpose of this project is to create random data classes, collections, all these kind of things for you
29:20
I use it in everything I do now because it helps me test this kind of information with completely random data, right
29:28
Which will break code. I know there's a lot of database people out there and they test their code
29:35
It works fine. And then one of your users has a last name that has an apostrophe in it, right
29:41
Breaks the query, right? This is what I'm talking about. And you're going to test must because, you know
29:49
a lot of teams are or should be moving to continuous integration
29:54
And you really need to think about how you're doing your unit test and doing stuff like that
29:59
because it has to run in GitHub, right? Or some other system, right
30:04
So the unit test must be reproducible in continuous integration builds, right
30:10
Otherwise it won't work, you know? And this is actually something I'm going through right now
30:14
with my open source project is I've tested everything myself and everything works great
30:18
But when you put it into CI builds, some of it starts falling down
30:22
and I've had to go back and rewrite some of my unit tests. So my tip for this section
30:28
is do not ever commit code that doesn't pass 100% of the unit test
30:35
So, you know, if some developer checks in code and they haven't run the unit test locally
30:40
you need to, you know, give them a red flag or some, I don't know what it's called
30:46
But please don't check in code if you haven't run the unit test
30:51
That's what they're there for, right? Just don't, oh, I changed this one little thing
30:55
It'll be fine. I'll just commit it. You know, committed to the main branch
30:59
No. Run a unit test first. And this is where, of course, continuous integration can help
31:08
All right. What's next? Continuous integration. Tom's still watching. So I know the one person is watching my keynote
31:19
So continuous integration in software engineering, basically, to me, just means that everything's being built in the cloud somewhere and you're running a unit test
31:29
right? Every check-in creates, I mean, every commit to the branch creates a build and then
31:36
hopefully that build's also running a unit test because you need to find out right away
31:41
there's a problem, right? So the developer can go fix it right away. I've been on teams where
31:47
I basically have been dead in the water for a day because some beginner, you know, checked in code
31:52
that wasn't tested, breaks the build, and we're all sitting around going
31:57
yeah, there's not much I can do until the build builds fits, right? So this is really where continuous integration
32:04
you know, it's just this loop of test, build, release, source control, developer reporting
32:10
This has to happen on every commit to the branches, right? Because this is how you find out the issues right away
32:18
And like what he was saying, you need to find the issues out immediately
32:22
not days later or hours later even, right? Because it can be catastrophic sometimes
32:28
So some of the common practices, I'm going to go through this kind of quick
32:35
because I know I'm short on time. So maintaining a single source repository, of course
32:43
automate the build, super, super important. Every commit should create a build
32:48
which is easy to do in GitHub. and makes your build self-testing very, very important, right
32:54
Because I think, I forget if it was Jason or what he said
32:58
that most of the stuff should be automated. The manual days of doing this is gone, and we need to automate this
33:04
and this is how continuous integration helps. And I'm really happy that at least the team at GitHub
33:11
is continuously making this process better for us. I'm not in love with these YAML files and stuff
33:17
but at least they are making things better for us. Commit to the main line every day
33:27
Every commit should build the machine on an integration machine or however you're doing it
33:32
but it needs to be built on a clean machine. And that's one thing I really like about
33:37
building in GitHub is that you're basically creating a brand new instance from scratch
33:42
every time you do a build. And so that will, using continuous integration
33:47
will really uncover some issues with your code just by doing a continuous integration
33:52
So if your project isn't in there, be prepared. Once you start trying to do this
33:57
it's going to create some work on you. And this helps you fix broken builds immediately
34:03
because like I said, this can waste hours of time and that can really add up time
34:09
Not only loss of features, but it can be very costly. You keep the builds fast, of course
34:18
You can test and clone a production environment. That's a lot harder to set up, especially in the cloud, but you need to do this
34:26
Environments, I'm going to be talking about environments next, but they must be easily reproducible, hopefully by just running a script
34:36
And it makes everybody easy to get the latest executable, and everybody sees what's happening
34:42
All this stuff is reported so you can see what's happening and your boss can see what's going on and see who's breaking a build and give them a ding at the end of the week, I guess
34:51
I don't know. And, of course, if you go into the automatic deployment, you can do that, too
34:57
I haven't really done this too much yet because, I don't know, I'm old school and I'm afraid of just letting it happen automatically without somebody saying, okay
35:06
But, you know, this can be important for certain things, too. And like I said, doing this will uncover many issues with the code and projects
35:14
And every team I work on and help set up their continuous integration, that's exactly what happens
35:19
We have to spend quite a bit of time usually fixing the code so it will work in continuous integration
35:26
Because it always works on my machine. Well, with continuous integration, you don't have your machine anymore
35:31
It's created for you on every build. All right. So that's enough about continuous integration
35:38
Next is application testing. I know we had a lot of talk about testing during the conference So again I going to try to go through this pretty quick But you know anything before it released to UAT
35:52
or production has to have end-to-end testing, right? That's all there is to it
35:59
This must be done before the release, right? And things are better these days as opposed to a bunch of people
36:06
all sitting in one room trying to do it all together. You know, a lot of this could be automated, thankfully, now
36:11
from the old days, but this has to be done with every release
36:16
And you can't just put it, you just can't change one little bit of code and put it out
36:21
It has to go through testing. You know, once any code is tested, it starts the whole, you know, cycle over again about
36:28
testing, you know, building testing, you know, user acceptance testing, all that kind of stuff
36:35
And this includes all layers. You know, I'm calling this out because it doesn't matter what layer you're on, whether it's the UI, communications, database or whatever
36:46
Everything needs to be tested before you do a major release. And of course, I've said this over and over again, automate as much as possible
36:55
There's tons of tools out there. You know, if you hired the right QA people who really love doing this automation, they're worth every penny
37:03
You know, I've worked on a couple of teams where, you know, I've had a really, really good QA automation person
37:10
And man, those people that really know how to do that well are very, very valuable
37:19
And of course, regression testing. You know, regression testing is rerunning functional, non-functional tests to ensure the previous developed software still performs like it did
37:28
Right. So, again, before any major release, you need to do regression testing
37:32
Make sure you didn't screw something up. You know, I don't think very many companies do this anymore because, you know, one version, something works
37:38
The next version, something doesn't work. And I'm talking to you, Visual Studio and other applications out there, too
37:45
And so this is why regression testing is super, super important to catch these things
37:52
And developers should never participate in this kind of testing. Right. We are not part of this
37:58
I mean, the actual testing part. We can help them out with issues and things like that, but we should not be testing our code like this
38:06
The way we test our code is unit testing. Everything else is done by somebody else
38:10
because we're the worst people to test it because we know how it works. So we are the worst people to test code like this
38:17
So make sure you have a great QA team available to do this, right
38:25
and a very knowledgeable team and knowledgeable about the project. And, you know, I'm going to keep talking about documentation
38:31
but this is why documentation is important because, you know, how can the QA people test it if it's not documented
38:38
Are they just supposed to guess how it's supposed to work, right? There's no feature requirements
38:42
There's no architecture. There's no documentation. How are they supposed to test it
38:48
Please tell me. I don't get it. All right. Next, proper environments
38:57
Again, I'm talking to the choir here, hopefully, but I do want to quickly go over proper environments
39:04
because, you know, especially the last company I worked at, you know, this was a nightmare
39:10
So you must have multiple testing environments for your code, right? And, of course, there's the dev environment
39:19
and that's just for developers, only for developers. This is where we can test something on a, you know, in the cloud or in the server or something like that
39:27
Not not. I'm not talking about our local box. I'm talking about a dev box
39:32
That's, of course, all these environments should be near to production as possible. Right
39:37
Even the dev box. And so depending on the project, you know, you need to at least have dev QA and production
39:46
and for larger projects and larger teams, you can also have staging and UAT
39:51
and we'll go over those, right? But, you know, the one thing I do want to point out
39:56
and I know this is pretty easy to do in Azure, is, you know, a lot of teams
40:03
what they do is they do separate builds. They do a dev build, they do a QA build
40:06
they do staging build, and they do a production build. This is really the wrong way to do it, if you ask me
40:12
because everything QA and above should be released, right? the release type of build
40:18
And so the right way to move your code is to move them from environment to environment
40:26
not a completely separate build, right? So the QA build, when that's been accepted
40:32
should move to the staging UAT environment, right? The exact same code, right
40:36
You might have to change the configuration, but the exact same code should move from QA to staging, right
40:42
And then once that's accepted, then that's moved to production. You don't go from dev to production
40:50
You use the exact same code build in these different environments. And it's super important to do this
40:58
And like I said, I know this is pretty easy to do on Azure. I don't know about AWS, but I know it's pretty easy to do on Azure
41:06
So the minimum proper environments, of course, the dev environment, and I just talked about this
41:11
only used by developers because we're always screwing things up and trying things
41:15
And, you know, we don't want to block QA and the other teams by our, you know
41:20
our screwing around with stuff. So, and of course, this will also
41:24
you know this will also what was I going to say I don know Somebody comment threw me off base So this is only for developers but it has to be not your local box
41:41
It has to be something in the cloud or a server somewhere else
41:47
Of course, then after the dev environment comes a QA environment to be used only by the quality assurance team
41:55
This is where they start doing their testing, their automated testing. all these kind of things, right
42:00
It's the QA environment. And developers should have no access to any environment except for dev, right
42:09
QA, UAT, and production, we should have zero access to. That's the access for DevOps people
42:17
So next is QA, of course. I know a lot of people, I mean
42:20
already know about QA. Super important to get some good QA people
42:25
and teams in there. And then, of course, after that comes the UAT or staging environment. And this is where not only the QA people can test, but this is where
42:35
your top users can start testing too. So they can look at it so they can, you know, give their okay
42:42
you know, before it moves into production, right? Because you want to get the users involved
42:46
And so, because we're not the users, right? The users are the users, you know, we're the worst
42:51
people that, you know, to test this stuff because we know how it works, right? We need to have the
42:55
people that don't know how it works necessarily on the testing. So that's why the UAT environment
43:00
is super important. And then of course, comes production, the final environment. And like I
43:06
said, engineers should have no access to production at all. And that should only be done by the DevOps
43:14
people. But the one caveat that I ran into with the last company I worked for is, you know
43:26
the problem was, you know, we had, you know, we had logging, you know, so we could find, you know
43:30
so we could log the errors and issues and stuff like that, but we had no access to the logs
43:35
because it was all stored on a server and they wouldn't give us access. So every time I needed
43:42
an access to a log. I had to tell somebody on the team. They had to contact somebody
43:46
in DevOps, and then we had to wait around for a while or a day
43:51
or more even to get access to a log. And how can we fix things like that in production
43:55
It doesn't work. So make sure you have your logs in the cloud somewhere. Yeah, in all environments
44:03
Make sure the logs are easily available to everybody, but especially dev people, right? There's lots of systems out there
44:10
Application Insights, Raygun, there's all kinds of systems out there. And it must be web-based so we can easily get to them no matter where we are
44:19
But, yeah, I could never get access to the production logs. So how am I supposed to fix anything
44:23
Kind of crazy. And, of course, all environments must be easily reproducible
44:30
This is really important and will take some time depending on what you're doing. You should basically be able to stand up an entire new environment from scratch by running a script
44:40
Right. Because doing this manually, like they did it, my last job can take weeks
44:46
I'm serious. And and so then we can't test and then we can't let things move
44:52
And it was just it was a nightmare. So this must be easily reproducible
44:58
Back in the old days, back in the 90s, we would rebuild machines entirely every night
45:04
That's how we did it. And but now we have the cloud. It's a lot easier
45:10
And the last thing I want to talk about is something very important
45:18
I think Jason talked some about this, and that's profiling. Very important, but rarely done
45:27
And so memory profiling is basically using a memory profile against running code in near production environment as you can
45:40
Right. And because, you know, I can tell, you know, we can talk until we blew in the face that this is the right way you should code
45:49
You know, this is the right way you should do iDisposable. This is the right way you should do arrays
45:54
We can talk about all that and you can implement it. But the real way to find out really what's happening is running a memory profiler against running code
46:05
And like I said, you don't run it on production because it really will slow down production
46:09
But you need to have it running on near the production code as possible
46:13
And you need to have people use the app or however the app is used and run the memory profiler against it
46:19
And it gathers all kinds of information. Application Insights actually gathers a lot of this information
46:25
But this is what we do locally. You know, I mean, dev developers do before we like release it to, you know, QA or user acceptance testing
46:34
And this is the only way to find the last bit of memory issues, pinned objects, disposable issues
46:44
I even found a bug in one of the HTTP classes from Microsoft that I had to report to them because there was a constant problem happening in one of their types
46:59
And I had to tell them to work on it. But I found it
47:02
And so this is why this is super important. And 100% of the companies I work for don't do this at all. Right
47:11
I never walked into a company and saw a company do this ever in my life And so when I get there of course I do that But even one company I said okay well we close to release so I going to do some memory profiling
47:28
And they said, no, we're not going to pay you for that. Oh, how can I guarantee good code quality if I can't run a memory profile against it
47:40
So, you know, I've tried a lot of the memory profilers out there
47:45
And the one I like the best actually is called the .NET Memory Profiler from Cytec Software
47:51
It's relatively because memory profilers can be very, very expensive. But this one is not expensive
47:59
And it will pay for itself the very first time you use it. I think it's only like $250
48:05
And the first time you use it, it'll pay for itself. I guarantee it
48:09
And I use this not enough, unfortunately, on open source projects, but I do try to use as much as I can
48:16
And this is a screen grab from that project product. And it will show you all the things you need to go look at
48:25
You can you can look you can drill down into the actual type, you know, that actually is causing whatever the problem is
48:33
And you can actually depending what you have turned on, you can actually see what values were in that type when that happened
48:39
Right. So much valuable information that maybe prof profilers give you. You know, the one caveat, one caveat, the one thing I should say is not not every developer needs this
48:52
Right. You know, most teams, you only need one developer that needs a license to this because memory profiling is very time consuming
49:01
And you really have to know what you're looking at. So so you know how to drill in and go in and look at things
49:07
But it's very time consuming. So if you do this, make sure you don't do it at the very end. You need to start before the end of the project, because this can be very time consuming. You know, going through everything that it produces, depending how long the profile was, is very time consuming
49:23
So all of you companies out there that are afraid to pony up $250 for every one of your developers, you don't need that
49:31
You just need like one or two developers to have a license. So I think everyone should, but you can get away with one or two
49:39
So if anybody listens to my words and actually starts doing memory profiling, please let me know
49:46
I'd love to know your experience. and go check out, you know
49:51
Domnet Memory Profiler from SciTech Software. I think my mouth is starting to screw up
49:59
because I've been up so long and talking so much today. So let's do some summary to wrap this up
50:06
I know everybody, if you, I think Simon and I are the only ones here for the whole time
50:10
but I don't know about you, but I'm really tired. I know Simon probably wants to go to bed
50:16
So summary, architecture, and documentation, all these things are very, very important
50:24
Coding standards, of course, unit testing, continuous integration, application testing, regression testing, proper environments, and, of course, profiling
50:38
Every project needs this. I don't care what kind of project it is
50:43
It needs these things because in the end, you'll not only come up with better products, but your developers will be happier
50:55
You know, you can be proud of your project. And that's what it's all about. We want to be proud of our work and be happy where we work and happy with the team
51:02
And this is one of the things that helps do that, right? Because if the users are happy, everybody will be happy
51:08
I guarantee it. and as I'm talking about this if your team needs help on in any of these things and even more
51:17
please please contact me and I can help you team out this is what I do I go into teams and
51:24
fix their stuff you know I was going to say crap but fix their stuff right um so please you can
51:31
email me uh or you can tweet at me and I'm more than happy to help your team out um and uh because
51:38
this is what I do most of the time these days and code quality and
51:42
performance is, you know, really what I'm focused on these days. And because I really like helping these things out, because like I said
51:52
I have a, you know, I have a motive and that's what the products I use
51:55
I want to, I want to like, right. And that's not happening much anymore
52:00
So this is why all these things and even more and everything that has been
52:04
talked about in this conference is very, very important to listen to and do. So we could have a good life and go to the beach, right? The
52:13
sun's kind of out today. I could go to the beach after this if I wanted to. So don't forget to
52:19
pick up a copy of my coding standards book or my code performance book, especially my coding
52:24
standards book. If you don't have a standard, get a copy and start there and create your own standard
52:30
or just use mine. If you want me to add something to it, let me know. I'll put it in. I'm always
52:34
working on the next version. I put out an edition at the beginning of this year. I really don't plan
52:40
to put one out probably until next year because I'm working on the code performance book right now
52:44
But if you don't have standards, you need to. And of course, my book is a great start to do that
52:49
And so thanks for attending the conference. Thanks for listening to me at the very end of
52:55
this and listening to the keynote. I know
#Programming