Engineering Efficiency
As I was setting up my wife and my wedding website[1], my wife's portfolio website[1], this blog, and a few other projects, I learned a few new things about software engineering.
The first lesson I learned is that overcomplication kills productivity.
I learned this lesson when I first started setting up the portfolio website. I had a PHP-based draft of the portfolio site mostly finished, but it got to the point where I had to ask myself if it was worth the effort to design yet another php based cms. I know HTML, and I had recently set up an AWS account for the wedding site. I decided to leverage AWS's S3 service instead of building a dynamic site with database backed shenanigans. Side note -- why are all blogs categorized as content management systems? I suppose they are technically content management systems at their core, but they offer a very limited subset of CMS functionality[2].
Building the static site took the better part of a weekend. Total development time for the php version? About 3 weeks.
The architecture of the static site is fairly straightforward. I have a few user-editable JSON (or HTML, or template) files on S3, which are dynamically pulled by the javascript on the front end. This lets me use a CMS-like approach without having to worry about all of the security implications of running a dynamic site with a database backend, and I can leverage S3's authentication and a few scripts if I need to update some content.
The site really is platform agnostic, I can host it just as easily from any web host since it is just html and javascript. Any dynamic aspects of the site can be written in javascript and executed on the client side. I can use S3's (or any other server's) rules to redirect 404 pages to a /#!/ style url, after which my front-end can fetch alternative content (be it an error page or just some content) via ajax and render it. I use links with both href and data-href properties to support graceful degradation progressive enhancement, the site works perfectly with [javascript disabled](http:// noscript.net) for all those who will not use javascript or -- more importantly -- cannot use javascript.
The href points to normal pages, while the data-href will replace the href if javascript is enabled. The data-href links point to pages which have some logic to set an iframe src and put a title inline in the page. Easy way to link to clean portfolio pieces and include some commentary outside of them. It also lets me serve "dynamic" pages via a static web server.
I would not have done any of this if I had continued with the php-based implementation.
And yet, this version of the site took a significantly smaller amount of time to implement. It is more feature-rich and was completed in significantly less time -- an order of magnitude in fact. This is because I focused on the features which mattered -- what the consumer of the site would see, while leveraging other pieces of software for the things I knew I did not need to implement. Things such as user authentication; databases; security; content generation/curation; and asset management, vulnerable to XSS attacks. This site has no vulnerabilities beyond what is inherited from AWS/S3. Amazon is extremely motivated to fix any vulnerabilities in their infrastructure, as they have many huge clients which would be instantly and irreparably impacted by such an infrastructure insecurity[3]. Therefore I am leveraging their security and authentication code as well.
Eventually, I will write[4] an infrastructure to support this website. I will add templating support, one-click site compilation and upload, versioning (with git of course), and more. But the fact of the matter is that this site took me only a day to get all the necessary functionality[5] implemented, and there was relatively little engineering overhead.
In closing: software engineering is about solving the problem, not flexing your mental muscles. Lines of code and commit count (or any other statistic which doesn't reflect ROI) are not valid metrics, time and effort spent is.
Footnotes:
1. ^ My wife designed the layout; I put that into HTML and javascript. Perfect (non-symbolic) first shared task for us.
2. ^ Static pages are sometimes a hack, for example. Another example is that actually linking to static pages is next to impossible (without editing your template or putting the link in a post) on some blog platforms.
3. ^ I don't think insecurity is the right word here; I'd have used vulnerability if it weren't for the alliteration.
4. ^ Or fork and update.
5. ^ For a website, necessary functionality includes having content and linking it together. All other functionality is just fluff. Simple is the new black.