[Eldorado.Railroad]

I post this here as a reminder to both users and (new,wannbe,old) developers what Open Rails is up against. I often see trends in this project come and go, and with that, I feel that we lose sight of what is important. Some of this might not appear to be directly applicable to this open source project, but by thinking a little "outside of the box" you might be able to see how it fits. With the "idea" that was floated of recent, of hiring a paid developer with an unknown source of funds I post this here.

Steve

Reprint from https://olano.dev/20...more-than-read/ :

Code is run more than read


Code is read more than written
This phrase is, by now, common programmer knowledge, a reminder that the person first writing a piece of code shouldn’t buy convenience at the expense of the people who will have to read it and modify it in the future. More generally, code is read more than written conveys that it’s usually a good investment to make the code maintainable by keeping it simple, writing tests and documentation, etc. It’s about having perspective over the software development cycle.

Let me express this idea more succinctly:

maintainer > author

I think this line of thought can be extended beyond code-writing and used as a rule of thumb to identify problems and make decisions.


Code is used more than read
Code is a means to an end. Software should have a purpose, it’s supposed to provide a service to some user. It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user:

user > maintainer > author

Or, since we won’t need to distinguish between developer roles anymore:

user > dev

This is why, instead of guessing or asking what they need, it’s best to put the program in front of the users early and frequently and to incorporate what we learn from their feedback.

This is a strong mental model, just keeping the users in mind during development can get us quite far. It’s approximately how I learned the job and how I understood it for the first half of my career.


Code is run more than read
When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc. As Dan McKinley puts it:

It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.

We can incorporate this idea into our little model:

user > ops > dev

It took me a while to fully grasp this because, in my experience, much of the software being built never really gets to production, at least not at a significant scale. Most software is built on assumptions that never get tested. But when you run your code in production, the KISS mantra takes on a new dimension. It’s not just about code anymore; it’s about reducing the moving parts and understanding their failure modes. It’s about shipping stuff and ensuring it works even when it fails.


Also, there’s business
I said that keeping the users in mind during development can get us very far. This works under the assumption that software that’s useful and works well, software of value to users, will be of value to the organization. It’s a convenient abstraction for developers: we produce good, working software, and the business deals with turning it into money. And it mostly works, especially for consumer and enterprise software. But, eventually, that abstraction proves to be an oversimplification, and we can benefit from incorporating some business perspective into our working process:

biz > user > ops > dev

The most obvious example is budget: we don’t have infinite resources to satisfy the user needs, so we need to measure costs and benefits. There’s marketing, there’s deadlines. There are stakeholders and investors. There are personal interests and politics at play. Decisions that make sense for our software, our team or our users considered in isolation, but not when we consider the organization as a whole. Sometimes, we need to work on what generates revenue, not what pleases the user. I’ll get back to this.


Smells
We arrived at a little model that expresses the relative importance of various factors in software development, one that can perhaps help us see the bigger picture and focus on what matters. Now I want to look at some common software development dysfunctions and see how they map to the model.


Unmaintainable code
author > maintainer

This is where we started. This is clever and lazy code that turns into spaghetti and haunted forests, this is premature optimizations, this is only-carlos-can-touch-that-module, etc.


Unusable software
dev > user

Software from teams that don’t learn from their users or that put technology first. Over-engineered programs, “modernizations” that degrade the user experience, web apps that break the browser features, etc.


Works on my machine
dev > ops

Software that wasn’t designed with its operation in mind. This is overly complicated software with lots of moving parts, fancy databases for small data loads, microservice ecosystems managed by a single small team. Software prematurely architected for scale. Software designed by different people than the ones woken up at midnight when it breaks.


The right thing
dev > biz

Code considered as an end in itself. Software built by pretentious artisans, musicians of the Titanic, and Lisp Hackers.


Resume-driven development
dev > *

Software produced when there’s nothing at stake and developers get to do whatever they want.


Imaginary software
biz > user > ops > dev

This is software that’s built but rarely (or never) gets to production. I call this imaginary software. Charity Majors calls it living a lie.

biz > user > ops > dev

Another kind of imaginary software is the one that doesn’t have users. (But scales). This is software that doesn’t solve a problem, or solves the wrong problem, perhaps nobody’s problem. Software that results from taking some hyped tech and hammering everything with it until something vaguely resembling a use case comes up.


Late capitalism
biz > user > ops > dev

Venture-backed software without a business model or whose business model is grow-until-monopoly-then-exploit-users.


An elephant
If you didn’t rage-close the browser tab yet, let me wrap up by going back to this:

biz > user

This one has ramifications that can be hard to swallow.

As I mentioned above, the way I learned the job, software was about solving problems for end users. This is summarized in one of the final tips of The Pragmatic Programmer, saying that our goal is to delight users, not just deliver code. But, since I started working as a programmer, and as software became ubiquitous, I’ve seen this assumption become increasingly hard to uphold.

There’s a lot of software being produced that just doesn’t care about its users, or that manipulates them, or that turns them into the product. And this isn’t limited to social media: as a user, I can’t even book a room, order food, or click on the Windows start button without popups trying to grab my attention; I can’t make a Google search without getting back a pile of garbage.

There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals. And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either:

user > ops > dev
biz > ops > dev
biz ≹ user

[Weter]

Hello.

Quote

trends in this project come and go, and with that, I feel that we lose sight of what is important.

Feel absolutely the same.

And, really thanks for bringing that to our attention, Steve.

[ATSF3751]

Thank you for writing this Steve! I know this is a hard pill to swallow for many coders and users alike but its reality! I am the one that came up with the idea of starting a funding account for Open Rails development and possibly expanding our platform to open up to a broader audience.

When I talk to others my age who play Train Simulator games most of them are like what is Open Rails? I have only heard about Train Simulator 20xx and TRAINZ. Then I have to explain what Open Rails is to them and I would really like to change that for the future and get more of the younger generation involved.

The more people find out about Open Rails and play it the better off Open Rails will end up becoming in the future but the fact is we need to expand on a few things and not just the coding aspect of it. The users of the game are the ones that will ultimately make Open Rails a success and I only brought up the money aspect of it so we can help get the word out about Open Rails to more possible users and help expand coding for the future. The way I see it Open Rails is really loosing ground with the younger generation as more Train Simulator games are coming out that are much more advanced in "eye candy" and even realism in some aspects of the game.

Being that Open Rails has only focused mainly on physics it is time that we all focus on other aspects as well because you can not "sell" a game with physics alone. Yes we have 3D Cabs, extra features like opening doors, windows, working FREDS, and other aspects of railroading that many other games also have and that is all good but when playing Open Rails to me it still has that MSTS Feel to it and now is the time we start to break away from that feel and make Open Rails its own. Yes I know all of the coders are doing this on there free time but the coders need to listen to there users and "work with them" to improve the gaming experience!

Myself along with a few others on here are now working as a team with Peter to help expand the experience with steam locomotives for the game and I feel many other aspects of the game could be done in the same way. When it comes to Open Rails I have always seen it as the coders do what they want when they want and don't really work with the users to help them out. I know this is not always the case but there has been months where someone will work on a aspect of the game but then just quit and it will never be expanded on or not be touched for months or years on end.

I hope this forum will open some eyes because I feel we ALL need to work as a team when it comes to Open Rails no matter if you are a coder/developer or just a user of the game. Like Steve said I also feel like the Open Rails team has lost sight some times of what the end result should be. Remember Open Rails will never really be a finished game and only be expanded for future development as time goes on!

Brandon

[Weter]

Quote

coders do what they want when they want and don't really work with the users to help them out. I know this is not always the case, but there has been months where someone will work on a aspect of the game, but then - just quit, and it will never be expanded on, or not be touched for months or years

Agree again.

[Genma Saotome]

Spot on!

I'll add another example to one of your points:

User > Dev

Sometimes the least expensive and fastest solution is to help the Users (or Devs) fix their own processes. IOW code is not always the solution for what's wrong.

[Jonatan]

Steves post should be an eye-opener and lesson to ALL coders and software designers at big tech! :lol2: It was very entertaining and imformative. :good:



I stopped updating Open Rails after an unstable I found worked satisfactory, just for the reason people ping back and forth on code, which isn't even standardised between coders it seems.
One update seem to add something useful, then another update by someone else breaks it, forcing severe reworking of tediously updated engs and wags... then that's undone by another update. Or one update fixes a bug, then another update brings said bug back. It's not unlike dealing with Windows updates! :rofl2:

Only if an update adds something I know is very useful and desired for my specific needs will I run the OR updater. I've stopped at U2023.09.06-0007 for now; it does what I want and is decently stable.



As Steve and Brandon have pointed out, this is untenable so I keep out of it and have stopped requesting possible improvements or abilities, the coders can do as they wish. But the update that renders MSTS-style content unusable will be where I draw the line.

[Weter]

By the way: is anything known about v.1_6 (stable)?
(It was stated, 2 versions per year)

[ATSF3751]

What I would like to see from the coding side of things is working together to get the bugs worked out before going on to the next project or update. The way I see it and it has already been mentioned but the coders have to work together to get things done and be more pro active! Why do we have more then one coder working on the same coding? It would be much more productive to make a list on what others are going to work on and when?

Just my two cents!!

Brandon

[Weter]

Like multiple tailors, cutting-off each - a little piece from trousers, for fitting it, making "a bit shorter" - resulting a pants at the end.

[Siebren]

ATSF3751, on 03 December 2023 - 12:10 PM, said:

It would be much more productive to make a list on what others are going to work on and when?

For me, programming is a hobby now, not work. If I liked planned work, time schedules, stand up meetings for progress reporting, bosses asking when I'm finished, I would have continued working after my retirement.

Siebren.