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.
Building the static site took the better part of a weekend. Total development time for the php version? About 3 weeks.
/#!/ 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
data-href properties to support
href points to normal pages, while the
data-href will replace 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. Therefore I am leveraging their security and authentication code as well.
Eventually, I will write 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 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.
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.
Subscribe to Greg Cochard
Get the latest posts delivered right to your inbox