Of course it does. But that’s the wrong question. Because Agile Software Development is directly related to computing power and so it has similar scaling qualities.
According to GitHub stats, Hubot development stalled after 2015. There was a little bit of activity in 2017 and 2019, but not enough to consider the codebase under active development. I'm resuscitating Hubot.
Software is like a garden when you invest. You till the ground, plant the seeds and maintain it daily by pulling weeds, watering, checking for good and bad insects.
Building alpine Docker image for NodeJS app using node canvas and getting error from libcairo. The lesson learned is libcairo depends on the installed packages still being in the image and I wasn't including them.
I'm generating PDFs of purchase orders in dotnet with Playwright. The publish to Artifactory pipeline job starting failing with no indication why.
Your developers and their code have an antibiosis relationship.
I went through an excercise to develop a technology strategy for a fictional retail company which merged 2 IT teams.
As software engineers, we focus our time and attention on learning how to write flexible software; one aspect to building great systems. We often neglect non-coding, communication aspects of building great systems.
I don't use Chrome. I'm a rebel I guess. So when building Angular apps and practicing TDD, I wanted to configure Karma to use Safari instead of Chrome.
Application dependencies can slow down development because you're waiting for them to add a field to their API or update their module with the feature you need.
So with the talk of learning a design pattern and not trying to shoehorn it into everything, is SOLID one of those things where its use case is specific to a task or is it generally just something to follow?
I wrote about TDD in 2016. Since then, I feel like I've gotten better at it and have seen people use it less. So I'm revisiting the question, why is TDD so hard. I started a few conversations about it over Slack and LinkedIn. Here's my summary.
I never considered myself a process oriented person
We're growing. So in an effort to optimize the hiring process and improve the probability of hiring people who can do the job, we're thinking through our interview process. As part of that, we're researching Skill Assessment systems. Here's my first impressions with a tool called Qualified.
I wanted to host my website on IPFS. It's easy, but the links don't work. So I reached deep back into the recesses of my mind and found a fix.
I was just wonderin if this thing works with HTML
Naval Ravikant's tweetstorm of principals on how to get rich.
The way I see it, on one hand, there is no difference.
There's a lot of ideas about what MVC is and isn't. Here's my take.
STOP. TRYING. TO. SCALE. AGILE.
Domain boundaries, Component responsibilities ...
Seriously. Just use it.
About 10 years ago I was part of a meeting where the CEO of the company was trying to convey his vision of the company and it's core service to customers. I asked the room what the objective was and someone jokingly answered, "to make money" and the meeting continued ... and finished.
It's easy to fall into the trap of thinking that you could copy the Spotify model presented in Henrik's Spotify Engineering Culture Videos as a way to Scale Agile. Well of course it's easy. They're organization continued to be agile as they grew. Henrik really makes it look easy and amazing! It's really very aspiring, so it totally makes sense.
A dialogue about using Kubernetes, Cloud Foundry and PaaS.
agile adj. - Characterized by quickness, lightness, and ease of movement; nimble.
Routine enables us to move fast in a sustainable velocity. So we have 6 meetings during our iterations. It's simple, focuses on solving the "mis alignment" problem, and periodical (repeats every iteration).
Tony likes to push my buttons sometimes. He knows what my opinion is about how and why teams should estimate stories. So I get a text from him today, asking me what I think about Do Story Points Relate to Complexity or Time?. I'm compelled to bite. I can help it, but meh, it's easy to post things to the internets.
I've been working with my team to practice Test Driven Design (TDD) for about 2 years. They just started REALLY doing it about 4 weeks ago after I finally gave them the permission they needed to do it. And even now, they don't feel comfortable because it takes them longer to finish development. Below is my story of how I kick started the team practicing TDD and my observations of what I think are keeping the majority of Software Engineers from following the practice.
In order to reuse code, it must pass the teams measurement of readability and discoverability.
tldr; Building websites with content negotiation in mind gives you flexibility.
Or rather, you think there's going to be a conflict about a particular subject and so you don't even broach it. You don't even know if all the subsequent decisions and problems could've been avoided had you just asked.
I started out writing a verbose post about how to create a DevOps culture in an enterprise. After sleeping on it, I realized that people really need tactical suggestions on how to create a DevOps culture, not just a description. So here's a DevOps Culture todo list.
I want to work on a team who's culture has these characteristics.
I thought it would be interesting to post a version of Amber's article that changes the context from school to work.
Has your boss ever asked you to increase your code quality? How did you do that?
This has been a long time coming. I've preached about blogging for years and yet, have never done it myself. Well, I have but back in 1997 and I didn't keep it up and I don't have proof. And I'm a big believer programmers should write code and if you're a programmer AND gonna write a blog, you should write the blog engine yourself. It shows off your talents, or lack there of, and you'll learn something along the way.
I want to capture and share my journey about how I increase my work output as a software engineer by multiples of 10, 100, 1000.