Tag: Software Development (Page 8 of 20)

One of the ideas that intrigue me is the “ship it or die” mentality. Regarding what it’s called, there are variations thereof, but the idea behind the phrase is simple:

If you have an idea, get it from concept to product as quickly as possible.

Sure, the idea of getting to concept to a product may also be called “concept to cash” but there’s never a guarantee that you’re going to generate cash, right? There is a guarantee that you can get it into a tangible product, though.

And in software development circles, there’s always a lot that a person can argue for or against the idea. Off the top of my head, the two pros and cons that come immediately to mind are:

1. Pro. Getting something done quickly that works and that [potentially] generates revenue.
2. Con. Weak architecture, maintenance, scalability, testability, and so on.

In short, there may be a tradeoff between how fast you can get ship something for a market and the architecture behind the project. Sometimes there is, sometimes there isn’t. Generally speaking, though, I think it’s safe to assume the former.

Furthermore, some may see the former as the easy way out, some may see the latter as an exercise in YAGNI or, even more simply, that the problem can be addressed whenever it comes up.

But what does this have to do with anything at the moment?

Continue reading

The more projects I work on with people who I hold in high-esteem, especially as it relates to programming, the more I find myself wanting to pre-justify the reasons I’ve made a decision about how I’ve solved a problem.

This isn’t to say that I try to be defensive about what I’ve done from the start. Instead, it’s more of an attempt to try to justify or rationalize the reason I did something so the person reviewing my code understands it and doesn’t think ill of it. The thing is, I’ve never really had an experience – at least not in the last, say, half a decade or more – completely obliterate my confidence.

Code Review, Part 1 via xkcd

Instead, they’ve done one of three things:

• The person reviewing the code has made a recommendation as to how the code can be improved,
• The person reviewing the code has asked why I did what I did (either to better their understanding or to see if there’s not a better way the problem could be solved),
• The person has provided insight on how to rearchitect the solution simply.

And regardless of which of the above is used, I’m generally grateful.

Thus, one of the things I’ve been trying to get better at doing is merely deciding on how to implement a solution, commit the code, and let the code review process do its thing.

Continue reading

One of the most frustrating aspects of programming is working on a solution to a problem and bumping up against something that we should know how to do or be able to figure out how to do, but we’re unable to do so.

There’s probably a proper psychological term for this or an acronym given that I’m talking about programmers. 🤷🏻‍♂️

Case in point:

Let’s say that I’m working on a project and it has to make an Ajax request. I get the response, I display it, and I also cache the response for 24 hours.

If the user requests the information again, I pull it from the cache, and it looks fine. But what about whenever you’re the first person to hit it in the next 24 hours?

That is, you get a cache-miss, and then you get not only a longer-than-normal request, but you also get a response that needs some additional processing before rendering it to the user?

Reading this, you’ve likely got a laundry list of things you’d try to do. And I’d venture to say that everything you’re thinking is likely worth trying if not right.

Ultimately, that’s proving my point. And that’s this: When you’re not as close to the problem, it’s easier to find a solution.

Continue reading

When it comes to writing software, two of the most popular schools of thought are:

1. YAGNI (or “you aren’t gonna need it”),
2. and Generalization (or maybe “premature generalization”).

They aren’t necessarily exact opposites, but for where I’m going with this, it’s worth treating them as such.

In my experience, projects boil down to projects for customers or products that you’re building to sell. This isn’t to say we don’t build products for customers, so maybe it’s just easier to say:

• “Hey, I’m building this for someone else,”
• or, “Yeah, I’m building this for me [for profit].”

Here’s the thing: I often find that when it comes to building things for other people, it’s easier to want to go about Generalization for their code and YAGNI for our code.

So which one is right? Or is there even a right one?

Continue reading