Our Philosophies

These are the aims that with some big brush strokes say what we are about. Who knows where Mashoom is going to go in the future, but lets start with this.

Provide a product with the intent for it to work

The tech industry has a bad reputation (deservedly or not) for releasing products that don’t work, or only just work. Now, bugs in published software is inevitable, but when it happens it should be considered a problem and it should be dealt with like anything else of that nature; how do we make sure it doesn’t happen again.

No funny business.

Mashoom charges people money for us to provide them a service/product. Until further notice, thats it. The reason is simply, everyone gets what we are up to. Normal products are sold in exactly this respect, I think tech can be just as straight forward. Just because new and wonderful business models are possible through the internet doesn’t mean we have to have one.

We keep your data safe, to be given back to you when you want it

Much like a bank with money, a storage unit for stuff or your attic/shed. This is basically stressing the point above, we operate based on the money you give us, so therefore when we provide a service that requires your information it is kept safe and is for your eyes only, unless you say otherwise. Internet security is a problem for everyone at the moment, but like working in any unsafe environment you just must be very very careful. It is possible, companies prove it day in day out, but it shouldn’t be taken lightly.

Don’t treat the users like fools; clever software for clever people

This is about not trying to mask what the program is doing for the user. This happens for two reasons, one is that is the nature of some varieties of software, social media being an easy example. The other one is down to a programs sub level coding developing faster than its UI. You end up with UI controls being used for things they shouldn’t, or buttons for abstract things you don’t understand. The solution is for a better UI to explain to the user what is going on, thats difficult, but it is also the aim.

Function and abstract early

You can use the same code maybe twice, three times is a push and at 4 times you need to get a function going. The best and most useful bit of code is the ability to split commands up into function and objects. The benefit of focusing your code in this direction, is that the code base becomes much more maintainable, as each function can be worked on individually. Abstractions mean that you can literally change the fundamentals of your program without changing large amounts of code. Basically, do it.

Get GIT sorted… and the build… and the deployment

This as much a “I wish I knew sooner” as much as how Mashoom now operates. Too much emphasis is given to prototyping software and technology in general, when a huge amount of work should go into making sure you can reliably and precisely edit code, all the way up to your production setup. This means automating every part of the process between changing a line of code to it appearing on the server, so it is done the same way every time. This makes using and editing your code base feel more like tuning and improving a clever engine rather than stirring a code based porridge.

Use as many functions/methods as possible

OK, this obviously comes with some explanation. Basically if as a coder you think “O, I really want to perform this task”, you should be looking at your own functions and that of the language/libraries you are using to find a solution, before writing your own. This is simple, if someone has published a function to do that job, why not use it? Whether it be another person writing in your code base or an open-source project. Now, sometimes and hopefully often you need to write something new, but you shouldn’t start from this mentality from the get go.

No “one use only” code

This is code that can only be used in one way, normally it is designed for quite a narrow range of possibilities. There is a subtle difference between writing a specific function to do a job, and a function that is only every going to be able to perform a set task. Whenever you are writing a function it should be written to be as adaptable as possible, and internally it should be ready to be improved or extended. Again, one use code has its place, to quickly prototype a set of features or a product. However, I would much prefer to take a little longer in the prototype stage and produce a toolbox of code I can re-use again and again for many different applications.