Home » Posts tagged "best practices"

Reasons Software Architecture Matters

Several weeks ago, I was talking to a programmer and we got into a discussion about the importance of software architecture.  I maintained that having a defined architecture is important regardless of the team size, the person I was talking to asserted that architecture wasn’t necessary when there was just one person involved.

But here’s the thing.  All software has an architecture.  Even the most junior of programmers has an idea of how code should fit together.  At issue isn’t really about architecture.  It is about having a defined architecture, based on experience and best practices, that will allow the team to develop the software in question as efficiently as possible.  Software architecture, at its core, says, “this is how we build software.”

To find the reasons why software architecture matters, it is helpful to think about what happens when there isn’t any defined architecture in place.  For the purposes of this article, I’m going to generalize on how architecture impacts teams and where appropriate show why that is also important when your team is just you.

Reasons Software Architecture Matters
Photo via VisualHunt

Continue reading “Reasons Software Architecture Matters”

How to Establish Peace to the QA vs Dev Battle

Have you ever noticed how, when QA reports a “defect” developers tend to bristle?  I first noticed this in myself a few years ago.  Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial?  I think so.

I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.

But first, why does this problem exist in the first place?

How to Establish Peace to the QA vs Dev Battle
Photo credit: m01229 via Visual hunt / CC BY

Continue reading “How to Establish Peace to the QA vs Dev Battle”

Are You Average or Awesome? 9 Ways to Improve.

The story goes that there were two men, Joe and Frank, who were camping out in the woods when a bear showed up in the camp.  Terrified, they decided the best they could do would be to stay perfectly still until the bear left.  Hopefully, the bear wouldn’t notice them.  As the bear was poking around, Joe says to Frank, “What are we going to do if this doesn’t work?”  Frank says, “Run!”  Joe says, “You really think we can out run a bear?”  Frank says, “I don’t need to out run the bear.  I only need to out run you.”

9 Ways to Improve
Photo credit: Internet Archive Book Images via VisualHunt.com / No known copyright restrictions

Continue reading “Are You Average or Awesome? 9 Ways to Improve.”

Are You Doing Angular Right?

I’ve written that I’m using Angular to write a couple applications before.  One at my main contract and a couple side projects.  I know I’m kind of late to the game, but one of my frustrations with the documentation around Angular is that very little of the sample code that you can find on the Internet shows the sample using anything close to a best practice.  That’s the danger of writing about something you are too familiar with.

So, in this post, I’d like to cover a few best practices that I’ve discovered, or implemented in my own code, and explain in a bit more detail what is going on inside the controller.  I concentrate on the controller because this is a place that will be used the most.  Once you understand it, the rest of what you need to know will trickle down to services, factories, and directives.

image

Continue reading “Are You Doing Angular Right?”

Raking Leaves and Writing Code

So, today I had the task of removing the leaves from my yard, which gave me a lot of time to think because it is a pretty solitary job, even if you have people helping you, because much of the time I was using a leaf blower.  It is pretty hard to hold any kind of conversation when you are using a leaf blower.

And  as I was running the leaf blower, I was thinking about what I was going to talk about today.  And then it struck me, why not just talk about cleaning up the leaves?  I mean if John Sonmez and Scott Hanselman can talk about stuff that isn’t necessarily programming related, why can’t I?

But then I realized, I could talk about cleaning up the leaves in my yard AND talk about programming at the same time.

Think about it.

Why Rake Leaves?

Why did I clean up the leaves in my yard?  It wasn’t to make my yard look better.  No one can see my yard from the road.  No one would care but my family, and they do care.  But even if they didn’t, we ultimately clean the leaves off our yards because doing that means our grass will grow better next summer by allowing it to see the sun now.  We do it because nasty critters live in leaves.  We remove the leaves from our drive ways and sidewalks so that snow removal will be easier in the winter.  In short, as hard as the work is to take care of our leaves in the fall, the work is worth it because it makes the rest of the fall and winter easier for us  in the long run.

What’s interesting about the first reason, allowing the grass to get more sun during the fall months, would mean that it would actually be better to clean up the leaves frequently during the fall rather than waiting for them to all fall and then rake them.  By the time I get to them, it is probably too late to do any real good because I wait for them to all fall before I remove them.  By that time, the sun shines less during the day and the frost has already kicked in.

How Is This Related to Code?

And that brings me to our code.  We all have code that needs “raking”.  You know you have code that is duplicated all over the place, but have you taken any time to collect all of that code into one place as a function?

How many code smells do you have.  Are your functions long?  Do you have conditional blocks nested more than one deep?  Do you have classes that do more than one thing?  Have you written code that isn’t being used because “we might need it some day”?

As I work with inexperienced programmers, the one thing I notice is that looking for places to simplify code is a skill that needs to be practiced.  It doesn’t come naturally.  Very few programmers assume that as long as the code does what it should, they are done.

And yet, leaving these code smells in place means that the next time you go in to work on the system, you will not be able to understand the code as well as you should.  Because you haven’t let the sun shine on your code, when you get to it to maintain it, you’ll be working in mud instead of nice green grass.

The Challenge

So today, your job is to find one place in your code that could be made better.  Make it less complicated.  Make it fewer lines of code (without making it hard to read).  Find two places that are doing essentially the same thing and turn that code into a function.  Find two classes that are tightly coupled (highly dependent on each other) and remove the dependencies.  Do this once a day for the next thirty days and see if you don’t find your code easier to work with than it  is today.