Today software development looks pretty fragmented and complex depending on what angle you're coming at it from. I've spent the past decade building web apps, distributed systems, infrastructure and all sorts. My feeling is that as a developer there is still so much that stands in my way g...
Share your thoughts!
I often consult other teams in my company on technical issues and architecture. Coming from this background I always wish the following would be covered:
- The project should start up with one click or one command. It's fine if I need to configure credentials or something similar, but beyond that, your project should be so easy to start that your mom could do it. If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong.
- The underlying architecture and rationale should be documented and this document should be reasonably up to date. Whoever is the lead developer on the project should be responsible for this. Not all details need to be covered, but the main principles and the driving business requirements behind it need to be clearly stated and up to date. If there's no broad documentation, I consider the project to already be off the rails, not just heading that way.
- There should be a concept of testing. You don't need to have tests yet, especially if you're still prototyping, but you need to have a very clear idea of what you will test, how, and how you'll get there.
- Formatting isn't a discussion point. Whatever stylistic preferences there are are covered by linting and automatic formatting. If I clone the project, it should be reasonably hard for me to do things the wrong way and fairly easy to do them the right way.
- Branch management, code review, etc. All of this falls in the same pot for me, no one should have the ability to push directly to master, all changes need to go through review, pass lint, tests, etc before they can be merged. Doesn't matter if you're the lead dev or a summer intern.
You'll notice that all of the above are procedural issues, not code specific issues. I firmly believe that by nailing the underlying process first, you make it easy to build good software and hard to build bad software.
> If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong
I disagree here slightly. I think it's reasonable that a database setup may be necessary, especially if abstraction layers (ie. ORMs) aren't being used for SQL, and SQLite is not your database of choice. Sure, you could set up docker, but not every project adopts or even likes docker.
Perhaps the point here is that it shouldn't be necessary to separately configure a database from the command used to fire up the project. For example using Docker w/ docker-compose, a single command should be able to get most projects up and running with all of the required system dependencies included (database, etc).
I also have a small caveat. If you have a docker setup or a similar style of setup, if it is not obvious how to do this by hand, then you should write documentation on how to do it. Honestly, my standard is that you should have the same level of setup instructions as you would expect from a good open source project of the same complexity.
For the first point how would you handle software that needs a database of some sort? Or are you saying the project ought to include an install script that handles dependencies?
Not OP, but I've used containers to run temporary local databases for development.
If you're also packaging your application as a container you can use container orchestration tools like `docker-compose` to compile your app and up a local dev environment with all your external dependencies with a single command (eg `docker-compose up`).
Ive typically done this with Vagrant (virtual machines) + ansible but docker seems to be the new hotness. However a vm is what i run in prod so keeping docker out is one less tool
One project I've recently come across that illustrate a lot of what you're talking about is the Reaction e-Commerce framework: https://reactioncommerce.com/
The thing is so over-engineered that they had to do a makefile that clones the project for you. And I don't know what they're doing, but the thing is unusable on a Mac (it's supposedly related to filesystem operations in Docker -- why are you doing so many?).
I could go on and on. I spent 2 days trying to make this work properly, but in the end I decided that if I need to do a Web store, I'll go with something else.
Also evaluated Reaction ~9 months ago and came to the same conclusion. A React/Node eCommerce framework sounds like an interesting possibility but this project looks like a hot mess.
If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong
Backend project? you need to provide a docker-compose setup. Not just for the database, also for any other service like Redis, ElasticSearch, etc. If you're expecting PRs, you'll also need a good database unit test suit, preferably running something like Sqlite.Frontend? ideally you'll provide the API setup like before, but I'll settle for a dev env online.
This depends on the goal of the creator, whether it be a developer or a company. If they are selling a hosted version of the product, their incentive is to make the self hosting experience as bad as possible to incentivize potential customers to buy their product.
The one click start up point makes a lot of sense for Frontend developers! Auto installing a DB in the same command you use to run the app is pretty dumb though. What if I just want to point my instance at staging for testing? Now I have to have docker installed
there is still so much that stands in my way
My experience is that technology has never stood in my way. It may be inconvenient, but I always find a way to work with it.
The thing that has always been in my way is other people. Always.
For me:
1. A boss who has a clue. Who has actually built software deployed to production at least once. Who understands the customer's business. Who manages things and leads people, not the other way around. Who gives me my assignments, the resources I'll need, and leaves me alone.
2. Project managers who know how to run projects.
3. Business analysts who know how to conduct analysis.
4. The decision to either go agile or not. No more sprints, stand-ups, scrum masters, product owners, retrospectives, etc, etc, etc, unless we do it completely and do it right.
5. Anyone, anywhere who writes something, anything down. No more, "Don't you remember when Sue asked Michael and he got Fred to tell us in that skype?" (My answer is always, "No.")
6. Any environment where I spend 90% of my time programming and 10% on overhead, not the other way around.
7. Authority to go along with my responsibility. I'm tired hitting every deadline and forced to wait weeks (or months!) for Peer Review, Code Review, Design Review, Standards Review, User Acceptance Testing, Integration Testing, Quality Review (against what standard?), Steering Committee approval, Leadership approval, approval from God herself...
8. A minimal acceptable competence level for my teammates, achieved by proper vetting (including tech interviews and tests). Software development is achieved as fast as the weakest link, not the strongest one.
9. No meetings!!! If it isn't written down, it isn't. If it is written down, you probably don't need to meet.
I could go one all day, but I'm late for a meeting. :-(
You nailed it. 100% agree.
I don’t know about you guys, but .NET Core (c#) and Visual Studio along with Blazor on the front end and deploying on Linux is pretty darn cool and highly productive. I haven’t had much success getting as productive on Python, Golang, or Node. Blazor eats TypeScript for lunch. Sometimes people confuse complexity for productivity. You can’t tell me installing 60,000 NPM packages just to have one dependency break is your idea of fun.
I strongly believe that .NET Core/C# + VS2019 is easily the best option for productively shipping business features right now.
We also just started working with Blazor in production. There are still some rough edges in my opinion, but the conceptual model is very powerful. We currently use it in a limited internal system w/ server-side hosting model.
I do not think Blazor is an ideal technology for hosting netflix-scale applications, but for those highly-interactive/evented interfaces that you use for various business administration duties and expose to 10-10000 users, it's absolutely perfect. Being able to directly call C# business logic and subscribe to CLR events from your view logic is much more empowering than being forced to suck JSON through a straw, hoping client/server contracts are still lined up, and praying that all your complex XHR/websocket logic is pristine regarding error conditions and retries. Also, absolutely no NPM bullshit is required. I don't even have NodeJS installed on my machine anymore. All the javascript you will ever need can probably fit in a single static file. Our JS blazor interop shim is ~120 lines and it handles some incredibly complex client-side duties (get client rect for positioning elements server-side, subscribing and unsubscribing to events, etc).
JS dev here, I'd just like to say that the final sentence is just plain wrong at this point. Package locks are a thing and I don't actually remember the last time my project broke without myself having been behind the change that did it. My setup is actually pretty stable so new packages are pretty much never added either.
I've got used to the fact that outsiders aren't ever up to date with whatever is happening on the front-end.
Nobody ever seems to remark on how most UIs these days manage to be incredibly complex compared to how often they crash. Whereas if you look at older software or OS GUIs, the simplicity is astounding while still having more crashes. The point being that despite the bad rap that frontend dev gets, it’s actually made progress on the UI development front that is pretty much unrecognized.
I totally agree with you, but production deployments are terrible. The confusing way to handle secrets and environment variables, the lack of a standard database migration tool that is not tied to EF, the lack of a good standard integration layer with nginx... it's just a pain if you don't have a dedicated devops team.
Yeah that’s always been the big weakness in my experience. MS does offer a great developer experience but the deployment experience is still a long way behind Java and Go. Slowly moving in the right direction but windows containers are still a 2nd class citizen for example.
Oh and don’t forget Microsoft will probably sunset your chosen framework (such as WPF) and the 3rd party OSS ecosystem is much smaller. Oh and round here dotnet roles pay less, the final nail in the coffin for my MS dev experience!
Are people really using Blazor in production? What does your build pipeline look like? What dependencies/frameworks are you using?
I'm no way expert in Blazor but I wrote small post of how I setup Blazor Web Assembly using Github actions to Digital Ocean - https://www.integrated.ee/posts/dotnet-blazor-github-actions...
Yup. For a large desktop LOB app. Had to reinvent a few wheels because Blazor is so young (have high hopes to open source some of that). Build automation is a lot simpler for desktop-world. We do wish the framework and community were more mature, but are nevertheless very pleased with our decision.
.NET + visual studio + r# is the godlike stack. Haven't tried blazor yet but even asp.net is years ahead of the node ecosystem.
I'd say .NET Core with Jetbrains Rider is even better. :)
I am super excited to try out Blazor as well. I believe its the basis of the Azure web platform frontend so anyone can try it out just by signing up to the free tier. For me, I'm looking at rapid web ui prototyping. The ability to deliver a native-feeling web experience to a client in mere hours ;)
I'm interested in trying the .NET Core and Blazor stack.
However, "Visual Studio" is not my idea of the ideal developer experience... Maybe if the projects could be developed in VSCode
I tried out Blazor when it first came out. I really liked it! But at the time it wasn't quite production ready. Has that changed?
How does blazor deal with the situation if one client accidentally or maliciously triggers code that eats up CPU?
I'm also highly interested in any other information about your setup!
So I guess I should stop doing everything else and adopt a brand new M$ tech that totally blows out of the water what M$ offered a few years ago, which M$ said totally blows out of the water what M$ offered before that.
Got it.
It isn’t 1999 on Slashdot anymore. Using a dollar sign on a site dedicated to an ecosystem surrounding venture capital and all its friends just makes you look hilariously out of touch.
Yeah, poo on Microsoft for being a successful capitalist entity, said the community of people who work for, want to work for, or find a living supporting FAANG or the advertising and VC ecosystem propping it up.