Standard Patterns for SMB Bespoke Software Development

scottalanmiller

Lots of SMBs want to make their own software but don't know where to start and these initial decisions have big ramifications later. Think about starting with PHP, HTML5, MariaDB and maybe even deploying to Linux from the very beginning! Keep it simple, avoid technical debt.

scottalanmiller

Transcript:

Today what I want to talk to you about is a standard pattern for developing bespoke or in-house custom software for
the small business market. in SMBs it's relatively common that someone wants to make a small application, and
traditionally we used things like MS Access and some stuff like that to do this. And that's been less than ideal, and I think
most people understand that they don't want to do that, but a lot of people don't know where to go other than "not
Access" and that leaves some problems as you can kind of skew off in all kinds of directions as you try to figure out what
you should do rather than focusing on what you shouldn't. One of the problems here is that there are so many
ways you can make this work, but there's only so many that really make sense in the majority of circumstances and that's
why we kind of have a standard standard pattern.

It's not a best practice, it's nothing like that, but there is a pattern of how to approach this as kind of a baseline of "unless you have a reason not to do things this way consider that this is probably the way to do it", and what that is is want so a couple things: one - your application is going to be web-based unless you have a really strong technical reason why it can't be and you'd better be sure about that. It's going to be web-based - that's what a modern application looks like and it's
what a modern application has looked like for a long time. Do not assume that you're going to start with something
else and only go web-based if you have to; it's you assume you go web-based you're going to have a web interface and
there are situations where that doesn't apply, but don't start somewhere else start with the baseline move away from
it where it's applicable to do this.

The language of choice if you are not already a competent programmer in some specific language is PHP; not because PHP is the most amazing language ever, not because PHP provides us all kinds of technology we don't have other places,
but because it is simple, it is universal, it is very functional, it is custom designed for this exact use case, and it is super easy to find people with experience in PHP to help you whether it's online or you've got to hire someone or your company needs to maintain this in the future. For all of those purposes PHP is the ideal language, not only that but if you need to hire PHP they tend to be lower in cost than a lot of other languages.

You are neither constrained because it is a language that is very hard to learn or very obscure like f-sharp or Ocaml or
something like that, nor are you charged a premium because you're dealing with a language that is archaic and the only
people who would be using it or people who are trapped with it say COBOL or Fortran or Visual Basic. So PHP really
fits into a perfect spot here where it meets all the checkboxes that you would reasonably have for a normal business
application.

If you need something other than PHP chances are you will know and it won't actually be that you need something else it's that something else will have a specific benefit that makes sense. For example Ruby on Rails - you may already know Ruby or you may be interfacing with other Ruby components - so Ruby on Rails might make great sense or you may be a Python developer already and Python with Django just fits your needs. All that's fine, but if you don't have something driving you to some other language assume PHP.

One of the really big reasons for this as opposed to say C# or VB.NET that a lot of people feel might be easier to use one PHP is easier to it's more universal in three it doesn't provide any lock in whether real or perceived to an expensive
proprietary platform. PHP allows you to deploy whether to a platform as a service provider or to your own systems
whether there are free ones or paid ones or whatever. It provides you the flexibility in the future to do what's needed - even if you have things today that lock you in that doesn't mean you should invest into that technical debt.

If you're making a new investment in new code it should be towards something that gives you the freedom to do what you
need in the future this is just basic protections basic best practices around developing don't create lock-in without very clear reason to justify it and sometimes even with very clear reason really really work hard to justify that locking is a terrible thing. So we also assume with the rarest of exceptions that your application is going to need a database to hold the data on the back end. Not always true, but certainly most times if you don't need one just don't use one. If you do need one look to MongoDB or MySQL as a lot of people have used that in the past, MariaDB is kind of where
the development is going in the future. A lot of the the best platforms or the most common platforms have moved to
MariaDB from MySQL for those who are not aware MariaDB is a drop-in replacement for MySQL. Don't don't consider those two different products. Just if you're if you're getting one go check out MariaDB to get that it that's really ideal if
you need a relational database that's on the the slightly leaner side. It is fast and easy and lots of people know it, but
it's it's not the most robust it's pretty robust it's a good platform but if you need a really powerful robust database or you're really versed in this one PostgreSQL is the other really awesome choice.

Both of these are all three of these really are completely free you have unlimited open source options. You can deploy to Windows, you can deploy to Linux, you can float deploy to BSD, you can deploy them Solaris, you can put it on Mac, you have no lock-in. You can put it wherever makes sense including unlimited free platforms and hosting without limitations. So you are free and clear to do what you need to do. That said it's also important to consider that relational databases may not make sense to you for you for your project. A lot of things don't people jump it to that a lot of times when they're making internal software and PHP specifically is super easy to work with MySQL or MariaDB. Most documentation kind of
assumes that that's what you're going to do there are loads of NoSQL options out there such as Redis or MongoDB or
Cassandra, all kinds of things, and they may make great choices for you, depending on the type of data that you're going to
be storing.

If you're making a really simple application you're probably going to lean towards traditional relational databases not because they make sense, but because they're easy and assumed but if you're doing a lot of things, especially if you're doing distributed software where you may need to handle like failover or unbelievable performance or geographically disparate locations, a lot of NoSQL options may be very very appropriate for you. And remember it is actually high complexity that tends to push you towards relational databases and simplicity that pushes you away - that's not a given thing, but like for example Redis is a key value pair database so it tends to be very good for extremely basic use case
whereas something like MongoDB is a document database and it's very very good for document style data great for
light posts on a website or tracking assets things like that it tends to be very very strong.

Whereas relational data but relational databases tend to be very good for financial data where you need really really strong relations between lots of different actors and objects. So there's a lot to choose from there, but make sure when you're looking at your database and your platforms that you're looking at things that are not going to lock you in unnecessarily for the future, because that will cost you potentially an extreme amount of money because what is minor technical debt today can be crippling technical debt just a year or two down the road. And when your successors come they may be very unhappy to find that you are in a situation where you've created an amount of debt that will cost them more than recreating the project to get away from.

So that's just a baseline to start with and I think really gives a strong almost every time we have a conversation which is
pretty often about how people are going to approach a problem like this the answer really comes out to being PHP and
bring a DB it's free, it's easy, there's so many resources for it, there's always someone to help you, it's a good place to
start only vary from that if you find your reasons you have to.