So as I mentioned in my last post I do have plans to continue working on software in my offtime. In fact I have been doing that quite a bit, although most of it thus far has been research, studying more patterns, and devops/technology demos relating to the newest thing on the .Net block-Blazor. More about that later, but for now simply put things have changed. Luckily when you’re the PM, Dev, and QA team for your own personal project and there are no due dates these things can happen fairly easily-this is definitely not the way that real software development works. But how do we combat change in an ever complex software world? I would lean on others here and deployment models that are tested and have proven scalable.
First things first agile is the hottest thing on the block in the software world but not everyone is agile-some people just do agile. I think this is the biggest source of problems I see in the industry today. Agile is the standard for workflow and its considered such a best practice that for some shops its almost an antipattern how agile is used but not really adhered to. We use the workflow to schedule meetings, but the software design is months in the process, the course can’t be changed without so many meetings that by the time the change happens its value is significantly lessened, and (my least favorite) we accrue technical debt simply because we have to follow some rigid plan, set in place months ago.
I see some of these problems, and I read and hear about others. Its a common problem and the best thing seems to be to try to steer things in the right direction. After all most of the people with the complaints are the people at the lower level, so the decisions get made and that’s the end of it (unless you fancy looking for another job). Personally I’m not a huge fan of this approach and I encourage people who think outside of the box and question every bit of process around them.
Lets start with the manifesto:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
How then can we enact each of these tenants?
Don’t get me wrong any stable software company will obviously need some process, but be free and liberal with how its broken. What works for one team doesn’t have to work for everyone, and I’d take an engineer who can solve a problem in an original way over someone who knows and follows the process strictly. While my journey is young it is very clear that software engineering is both creativity in solving problems and taking an engineering mindset to bring those solutions to people.
Favor things that work over things that achieve a preset goal. Goals should obviously be achieved, but a piece of software that works has value, whereas something that doesn’t or something that has huge technical debt (but follows some previously established pattern) has little to no value. Favor the things that work and the people that work.
I actually don’t experience the downsides of this one nearly as much as others do it seems, but from my reading and studies it seems like the product managers and developers are sometimes worlds apart (and naturally the customer even further away). The people designing, developing, testing, and using the software should be a small team-if you have to break up a large team into small units such that this kind of interaction can happen. I’ve found it invaluable, and if anything more would be better. I really don’t think you can over collaborate in software especially if its between the people with the domain (aka business) knowledge and the people who are going to implement.
Don’t do nothing. Don’t schedule another meeting. Give freedom to those who can respond to changes needed and bring quick solutions to bear. Importantly something I’ve heard in a lot of talks about modern devops and cloud style software is to favor replaceability over most other metrics. If something takes a short time to implement, even if its service life isn’t long as long as it receives a sound return on investment and can be easily replaced at the end of its service life, that’s a great piece of software! Large companies who are used to deploying to cloud platforms understand and embrace this, so learn from their examples and favor composable pieces that can be easily replaced over well-engineered monoliths that must be heavily tweaked to overcome even the smallest change in environment. Customer requirements, frameworks, deployment strategies, and testing methods in software seem to have about an 18 month service life these days, so if anything needs to last longer than 18 months make sure its composed of smaller pieces such that any one part can be easily replaced.
So I’m interested in this new thing Blazor-specifically the WASM flavor interests me but frankly I like most of the things the .Net team are doing in this particular area at least. I also have been cooling off to writing the type of software that is just sort of domain modeling. I don’t think that means I won’t use some DDD, but I do miss the conceptual challenge and the interesting mathematics of AI and specifically reinforcement learning. I don’t know what that means for my project specifically but I’ll just do whatever feels right. I would still like to use Blazor and I really see no reason that it can’t play at least a small part in a project like this. I also have a whole host of exercises in a large AI text I would like to get through a good deal of, and eventually I would like to study deeper into reinforcement learning. The idea really has just been striking me over the last few days as my other project cooled (mostly just because other online tools are good and I’m just not that interested in a large-scale domain modelling type system in my spare time) and so I’ll respond to the change and follow what interests me.
A note about Blazor though: I do think its a smart and quickly adapting technology that has a lot of promise. If you weren’t aware its basically a component model UI system that works for .Net core. It uses WASM (the hottest thing on the web right now) to bring a .Net runtime into the browser and does DOM diffing to bring a component style UI model to C#. Currently you can do a server-side deployment where all changes are routed via SignalR to the browser and in May the release of the WASM version ships allowing the runtime to download into the browser and run the features in the browser-backed by ASP.Net, any other server, or nothing. Support for PWAs and other cool web features is there and its an easy to use, pattern agnostic UI system that works for the web. Additionally they’re looking at electron and other native hosting models as well as native mobile bindings. Write your UI code once and deploy it everywhere-seems pretty good to me!