Building software is hard. Building great software is even harder. Meeting the needs of the user to getting a working version that can then be added to and maintained is where I have found the struggle. Making the system do something is fairly easy. Combining those bits into a needed workflow and also account for technical issues and how they should be handled is the hard part.

I have been a geek for like 35 years now. I have studied waterfall, UML, agile and all the agile variants like SCRUM since. F# caught my eye in like 2012. I have been interested in Adam's work he calls "Event Modeling" for the past few years. I have studied many books and watched many conference videos about software and the auto documentation advantages. All this leads me to my dream.

That dream is where the business (or user needs), specification, design, coding, acceptance (success) and the end documentation for programmers and the users are all together in a cycle. Yeah, I know that is everyone's dream and there are many consultants who are able to cash in that. Still seams that many shops/developers struggle.

I have a vision where this works. The concept. I have bits and pieces but I need more resources, technically adept and experienced people in order the get it worked out.

My desire is to use F#. Doing so has numerous benefits and maybe later I will details my thoughts on that. Type driven design and functional programming allows a paradigm where the specs are literally the code. By using name spaces, these can be separated into layers where they would match up lanes in event modeling. Scenarios build the vertical slices and wargaming the test... or something like that. Using Playwright would allow the build system to test scenarios and html page snap shots could be compared to ensure the screen is right. Using the code comments the help files and even in program help and reference could be generated at build. Same goes for programmer reference. Having a special view to read the structure of the code, the name spaces, the modules, etc. would then allow an event model where one could change a choice at a point and see the other paths. The paths would all be part of the scenarios and testable. Live spec-ing, live documentation, live coding, live building. It circles around and around and creates working software, documented software, documented business (user) work flows, helps find holes in any of those areas and all around makes great software.

This does not really mean that things go faster. Adam is always stating in his podcasts that event modeling does not mean there is less work, you have to put it in. The idea is to put the work in where it benefits the most for the final product.

Maybe one day I will be able to put each of the pieces together and actually make this happen.