Recently I’ve been talking to companies that want me to improve staff productivity. The opening conversation tends to be about the same: they pitch me on their company and what a “great place to work” it is. They brag about how smart the people are, how much fun everyone has, and how it’s more like a family that a bunch of co-workers. They describe all the perks like massages, video games, beer-on-tap, coffee bars, and how much everyone loves them. “Sounds like you have it all together,” I say after hearing all of this. “Well,” they reply, “I just wish we could get a bit more out of them.”
My Response to “How to *never* complete anything”
The following is my response to Ewan Valentine’s blog post “How to never complete anything” that I discovered on Hacker News. Once again, I ask for people’s indulgence for posting a reply on my own blog rather than in the Hacker News comments. I find writing on my own blog a bit easier than wading into the surf that is the sea of many perspectives.
My Response to “Are we over complicating software development?”
This question was posted on HackerNews by ian0:
I have recently been involved in the overhaul of an established business with poor output into a functioning early/mid stage startup (long story). We are back on track but, honestly, my lessons learned fly in the face of a lot of currently accepted wisdom:
- Choose languages that developers are familiar with, not the best tool for the job
- Avoid microservices where possible, the operational cost considering devops is just immense
- Advanced reliability / redundancy even in critical systems ironically seems to causes more downtime than it prevents due to the introduction of complexity to dev & devops.
- Continuous integration seems to be a plaster on the problem of complex devops introduced by microservices.
- Agile “methodology” when used as anything but a tool to solve specific, discrete, communications issues is really problematic
I think overall we seem to be over-complicating software development. We look to architecture and process for flexibility when in reality its acting as a crutch for lack of communication and proper analysis of how we should be architecting the actual software.
Is it just me?
I was going to reply to the comment on HackerNews, but I quickly realized that I had a lot to say, and it would not have worked well as a comment. Additionally, I felt that others might benefit from reading this question and my response in the future, and I worry that HackerNews comments quickly vanish into the ether never to be re-discovered by anyone at a later date.
A Far Too Brief Rough Outline of How to Approach Single-Date Estimation
In my previous “An Attempt at a Pragmatic Framework for Defining a ‘Senior Engineer’”, in the “A Process to Estimate Work” section I said:
“It is beyond the scope of this post to describe everything that goes into making a good estimate, but suffice to say a senior engineer views estimates as a difficult challenge to be surmounted, and as a result will normally ask for dedicated time simply to come up with the estimates.”
A commenter asked that I write an article on estimation, and this is my feeble attempt to do so.
An Attempt at a Pragmatic Framework for Defining a “Senior Engineer”
Brandon Hays’ article “The Conjoined Triangles of Senior-Level Development” made me reflect on all of the Senior Engineers I’ve worked with. If I were to guess, these would be the shared traits that lead others to declaring them “Senior Engineers”:
