Efficient use of tools: keeping it simple and effective
A common failing among software engineers of a certain (inexperienced ?) age is to seek to use new (bleeding edge) tools – irrespective of the added complexity they may bring. All programmers seek to learn new and useful methods and tools. All programmers strive to be current. All programmers fear getting left behind – an easy fate in a rapidly changing environment. The danger here to you, the client, is the added complexity brings maintenance problems. These new tools ( new languages, new programs) are rapidly changing, and you risk having to destabilize your production system in a year or two as you upgrade the tool or the support libraries they are built on. Our ethos; to keep your system as simple as possible. To use as few tools as we can, and to use those tools that are as stable and accepted in the industry as we can find. We like learning new things too! But a professional should do this on their own time, not the clients'.
Frameworks; any ROI?
A common theme in web programming are “frameworks”. Sounds good! We all can benefit from guidance; here the promise is of efficiency and being pushed into accepted software design practices. The problems as we’ve seen them are: 1) They can get in your way, forcing you work around them rather than making you more productive. 2) The MVC (model/view/controller) paradigm most suggest is often needlessly complex and frequently creates obscurities in code. 3) The ones we’ve used (or been forced into using as we pick up someone else’s work) are bloated; in one case the most simple project has to contain thousands of files. 4) Programmers must spend their time learning the idiosyncrasies of the framework (an anti-pattern), rather than invest in leaning the core language the framework is built upon. Frameworks were touted as a means of fighting “spaghetti code”, but we’ve seen more convoluted code in their implementation than perhaps anywhere else. We believe a good programmer deserves the freedom to create as they see fit. Perhaps we’ll find a useful framework eventually – but for the time being we’ll just say “NO!”