My first thought was the irregular shape of the walls affects the way automobile noises echo off of it, potentially contrubuting to slightly quieter streets.
Thinking one could use Linux on Apple's proprietary hardware without non-trivial problems was the first mistake. Really should have thought twice about installing Linux to an external drive on a system with it's own internal drive & bootloader too.
i did the same, it worked just fine. the only downside was that the USB device i used was to slow, so the result wasn't practical. and, i just can't deal with dual booting. i want my systems to be always on (or quickly restore state from sleep or hibernate)
At the software company where I work, I have seen the defects and half-baked implementations go by for years. Meanwhile, it's new features that development talks about the most. Recently it dawned on me that they profess to use the "agile" methodology. So now I wonder... Where does maintenance fall in the agile methodology? Am I mistaken that the balance of it's focus is squarely on development rather than sound design / correct implementation?
Agile software development frequently focuses on delivering a set of minimal features, i.e. an MVP. Too often that approach results in software that's poorly designed and implemented, immediately needing a huge refactor in order to get anywhere near being maintainable.
Maybe the issue is in use of the word "maintenance"?
Sure, it's fixing things that break as things are used, but it's not like it's replacing something that gets worn out with exactly the same thing, or cleaning, or IDK enough about what actually goes on for physical plant maintenance. Things like that do exist - log rotation, restarting processes / servers because of memory leaks that aren't worth tracking down - but, mostly, seems like software "maintenance" is more like post-release iteration cycles.
Some of these are about the pure tech ("here's a consequence to this design when under use that was not anticipated / handled"), others are product design ("turns out it needed to do something a little bit differently") or additional features necessary to make something useful, or just additional features to make it more useful. Or, you know, it was just built wrong the first time.
Seems like all of those situations are actually just more of the same iteration cycles as during development, we just call them "maintenance" for some reason.
(well, except that maybe they needed information and observation that are only available once it's under use...)
Agile is about gradual increases of business value. So, as long as maintenance lowers further costs it is a proper aim. Unless there's something else which can bring more value earlier.
For some businesses maintenance time never happens. For some it is an important stage before moving to the next iteration of new features. For some it is a daily process with dedicated teams. Every case is different. Agile is about practical agility :)
IMHO there should be no distinction between maintenance and new development. In agile you don't really have "green field" development, since development is iterative. Except for the first week, you are always modifying an existing running system.
i'll quote the last three sentences of the article:
"In the agile world, success is all about business value - regardless of what was written in a plan months ago. Plans are made, but updated regularly. They guide decisions on what to do next, but are not used as a success measure."
so, answering your question with that in mind, the focus should be on business value. does maintenance provide business value? do new features?
does maintenance provide business value? do new features?
Yes, and yes. In a mature company, maintenance provides more business value than new features. To list some of the maintenance activities:
- incident response. It is not uncommon for a company to have losses in the tons/hour or millions/hour if the primary process has a malfunction.
- organizational changes. No software exists in isolation; changing requirements in a connected component may require changes in your software component too. Developers may think this kind of work is feature development, but from a business point of view, it's simply maintenance. Because of the dependency by other parts of the company, this kind of work usually has stricter deadlines than "new features".
- Predictive maintenance. Identify weak points in the current setup, and isolate of strengthen them before they cause an incident. This includes evaluating technical debt. The value to the business is in risk minimization, and the rationale for this kind of work is predicated on proper risk accounting.
These requirements and processes are part of any proper engineering discipline; these are not marginal issues.
The trick is tempering those values of continuing to make money vs chasing down growth and new sales. With agile you’re always focused on short term. The next few sprints.
I'm just a support person, but it seems to me that it doesn't. At least, not directly. If it did, then development would be focusing on it.
Why not? Because the customer already paid. Because Dev wants to focus on getting new customers instead of catering to the ones who have already forked over the money.
"What do you mean feature X isn't working for the customer? It's working for us in our lab. Anyway, we're all focusing on getting new feature Y working in our lab now." - This is the attitude I am sensing below the surface. It's frustrating.
I really appreciate this article. It hasn't sold me on mist showers, but the panorama of alternative showering techniques was eye opening. Maybe the Dutch rain shower is for me.
Having used rain showers at various fancy hotels, I am not a fan of them. The ones I've experienced don't pressurize the water, they just let it fall on you - the experience ends up being closer to standing in the rain than to a shower, and that takes all the enjoyment out of it for me.
Here's my anecdote. Ever since I was about 3, any large machine fascinated me. Construction vehicles, trains, planes, even the garbage trucks making the rounds in my neighborhood, and the dumpster trucks making their rounds at my school. At least for me, it's simply a fantasy over big giant machines. Maybe not so different from how native Amazonian tribes sometimes mistook airplanes flying over the rain forest as gods.
Brings back some long forgotten nostalgia. Growing up in South Florida, where trains aren't much utilized, I was amazed as a little kid visiting Holland how much trains were used in Europe, and how big the model train scene was there. I'll always remember walking into a shop in Eindhoven that was like the most beautiful model train museum I've ever seen.
