June 7, 2018

My Ideal Developer Toolkit

Yesterday, I mentioned that one of my goals is to find, or more likely, to create work that incorporates all of these:

  1. something I'm good at
  2. something I get paid for
  3. something I'm passionate about
  4. something that helps others

Here's an idea of something I could build that might satisfy all those points.

I'd like to share some very rough ideas for a developer toolkit that I'd like to try and develop.

I've used a lot of different programming languages, frameworks, and software packages over the years.

No matter what programming language or stack your using, there are certain things you almost always need on every software development project.

  • version control
  • issue tracking
  • invoice and billing management
  • text editor or ide
  • build, release and deployment management
  • team communication tools
  • search appliances
  • database

These tools are usually viewed as separate things. They run in separate processes, often on separate computers.

This has always bothered me! All of these are software. Why can't they all be included inside a nice cohesive toolkit?!

For example, why is it that the overwehlming majority of developers choose to separate their application code from the database?

I think many, many applications, especially business apps would greatly benefit from having a small embedded database right there in the same process as the application. For example, I've found that embedding a pure h2 database inside java webapps can be extremely useful and productive, especially during prototyping phase.

I was also so happy when Datomic was released. I think the idea of Datomic is brilliant. Embedding as much of the database inside the application as possible really makes a lot of sense to me.

Similarly, why are the build and compile tools always a separate thing?

I think there could be a ton of benefits of having the build tools be part of the app itself. For example, when doing clojurescript development, I use boot to launch the app, and to build and compile the app as files change. Having the build tool right there embedded in my app is very useful. It's so much better than having to run a separate process to compile and build like most of the other software stacks out there.

I believe the same applies for team communication tools, and project management tools like invoicing and issue tracking.

For example, imagine a dev shop who builds their own issue tracking software using the same software development process that they use to build apps for customers. Everytime the team starts a new project for a customer, they could start with an app that already had an issue tracker built right in. I think this could open up so many possibilities! You could direct link into application screens from the embedded issue tracker. Or you could have interactive unit tests that run application code directly embedded inside the issue tracker. Also, authentication and authorization could be shared between issue tracker and application.

If you were to add an embedded version control, that would open even more possibilities!

The lisp and clojure ecosystem advocate the fact that code is data and data is code. After working in such an environment for a while, it's really tough to go back to environment where this is not the case.

I think the bottom line is that code really IS data. And data really IS code. Any software stack that goes out of the way to separate these two is putting up unnatural and unhelpful road blocks.

There are sometimes security concerns for separating code from data, but this is overwhelmingly the corner cases. I don't think security is any reason to throw the baby out with the bath water. In fact, I can imagine software being more secure using this sort of cohesive toolkit that I'm imagining.

Why not take the "code is data is code" idea and apply it across all development concerns and tools?!

I imagine one consistent toolkit that includes build tools, compilers, issue trackers, team chat, version control, search appliances all bundled right into the application.

This doesn't mean that all of these things will be used all the time.

This also doesn't mean these things have to be tightly coupled together.

Done correctly, building on fundamental software design principals, I think I could build a toolkit of reusable, cohesive, self contained parts.

My ideal development environment would be one that puts all of these tools together in one reusable, cohesive, self contained toolkit right there at my fingertips!

Now I just have to build it ;-)

Tags: goals software development