BRISK: Software Development Management that's Better than Jira

BRISK: Software Development Management that's Better than Jira

This is part of an ongoing series where I present some of my ideas for a start-up company or app. Some of these are really short and need further consideration. Others are more thought-out already and have extensive notes.

These ideas are copyright 2020 Crates Media Inc. Please don't steal them.
We welcome feedback and collaborators! Contact collab {a} cr8s >dot< net
Click here the rest of the series on new start-up company and app ideas!

Imagine ONE app with better communication than Slack, better time management than Google Calendar, and better project management than Jira. It has all of the templating and editing features of Confluence, but even better document search and ease of correlation when building out your stories, meeting agendas and relevant documents or designs.

Rather than working totally free-form, it has some conventions that restrict the way you can work, recommendations around when to schedule meetings (beginning and end of the work day, or before and after lunch), how long (ideally no more than 30 minutes, regardless of what it's about), how many people are allowed to participate (max of 8 in any meeting), what subject matter should be covered, etc.

Included with this application would be a series of videos explaining the decisions behind everything, to help people recognize what constitutes best practices for optimal efficiency at work.

It would include features to readily spin up meeting minutes or conduct sprint ceremonies, including story estimation with the story details linked to mock-ups on Balsamiq or Invision, or uploaded as attachments.

When creating stories, rather than leaving a free-form description, this system prescribes an opinionated way to structure your story details. It gives explicit details on how to structure your stories and epics, and even includes templates for very common cases like building out user management capabilities, role or attribute based access control, or other common use cases. Users might even be able to submit their own epic templates for review by the community.

We should seek to use machine learning to determine the footprint and process of common stories in software development, and train a model to understand what work is necessary for the most common types of solutions. It would also be valuable to be able to correlate stories with the code -- if we build a code hosting and code analysis repository alongside the solution -- because this would eventually facilitate our ability to train models how to build code footprints matching common use cases.

This tool should integrate with Git and allow the user to quickly spin up a monorepo for software development with support for certain frameworks, by leveraging `nx`. It would include scripts to facilitate rapid application scaffolding, including tests. It would enforce the same linting guidelines by default, thereby guiding developers toward using the same standards when starting up an app.

The app stores shared templates for commonly-sought views in one place, and a library of components as well, making it possible to dynamically render components and just create rich, complex applications on the fly, with limited technical expertise required, including tests and following popular conventions like standard-version or semistandard JS, Typescript, etc. Users build fully-functioning interfaces using a drag-and-drop WYSIWYG that renders single individual views at a time. When creating buttons from a WYSIWYG, we automatically generate the test coverage that goes with it.

Whereas Jira has attempted to solve every problem in every software development model, this tool would aim to give a more rigorous course for linking everything together, and eliminates the unnecessary items or configuration while putting a spotlight on the most critical elements of focus.

The goal here is to guide software development to follow common conventions under the hood, so that students of this discipline can very readily jump into a project using this framework and hit the ground running. They already know where everything is, and how everything works. We can sell certification and training around our approach, to make it even easier for teams to adopt the philosophy and realize its gains.

From the start of a project, we can guide users through building applications in an opinionated way, and we'll even generate the Git repo and npm packages for them, and give them scripts to quickly build out their own npm submodules (and even query the package repository before they create one, to help them avoid duplicating something for which there's already a good use case).

For users of React, we can take this a step further by instrumenting the React Admin library, which would allow us to make it very easy to drag and drop entire view templates or use cases like user management into the application, with minimal effort. For the first iteration of this tool, we'd probably only support React with TypeScript, with semi-standard JS linting, and React rules of hooks, etc. Later on down the line, we can roll in common use cases and code inspection for Angular, Vue, Svelte and other libraries (or at least allow other contributors to extend our application with these libraries).

Further extending the value of the tool, we can include automated licensing assessment (ie. BlackDuck) and software component analysis (ie. Veracode / yarn audit) as part of the base offering. This would make it easier for large institutions to instrument the tool with full confidence that they have the rights to resell their code.

We would probably need to partner with an external party for the full source code inspection, and maybe another party for application hosting, and another for application performance monitoring... but we can prescribe solutions for all of these, and roll them into the tool to make it easy for users to access features of things like SonarQube, code coverage reports, videos of end-to-end test successes or failures, etc.

It would be most ideal if a user could also, via a drag and drop interface, walk through a shallow-rendered application and easily specify the intended way users are expected to navigate through the app and perform common tasks. Even better would be letting the user drive through the app and perform a sequence of events, and then, to let the user name that sequence. For any input the user provided manually in a text field or dropdown, you can let the user specify whether to use the exact input the user provided when setting the test up, or a random string / number / decimal / dollar amount instead. This would aid in "fuzzing" when looking at the UI for accidental text falling out of frame, or common UI issues that could be detected with Jest snapshots and/or React Storybook.

When building out features from within the app's UI, unit test coverage should be generated automatically for most common cases, like selecting something and seeing if the event handlers are functioning. When a user makes external commits to the branch, warnings should be thrown if conventional commit protocol isn't followed, or tests are deleted, or test coverage has dropped.

Anyways, that's the general idea. Simplify everything and get it all in one place. Management of the entire operation, even extending to putting together a website to market the product and manage its sales to end users.


Ready to learn more about JavaScript development, organization and productivity tips?

Click here to read more articles on JavaScript, philosophy and life hacks!