Skip to main content

Enough is enough ... stop with the elitism ... now!

For my 300th posting I wanted to do something meaningful and I think I hit on it yesterday. I was talking to the CEO of a NYC startup. The product they are building is interesting and in many ways it may be version 2 (see mythical man month) and in some ways it may actually be a different product altogether. But what concerns me about this project is that they are moving from NodeJS, which was a complete and utter failure for version 1 and now they are moving to scala for version 2. The decision to use NodeJS was born when a frontend programmer thought that he could write sevrer code. Whether or not NodeJS was up to the task is not important. This person thought he had the chops.  Now version 2 is around the corner and a different group have been taking lessons learned and implementing the new version on Scala. Scala, as a language, is not evil but it is unjustifiably elitest.

Business people, hiring managers, HR departments, recruiters, team leads and architects... take heed. Stop implementing core systems in elitest languages and frameworks. You are not getting any extra points for implementing anything in erlang or scala. Bad programmers are bad programmers and they are not automatically better because they used a different language or framework. Using elite tools simply means that you are paying more with little in return.
NoSQL based technologies are elitist. Stay away from them. When NoSQL has as many tools as the current state of the art RDBMS does for reporting, management, monitoring, etc... then you have something. NoSQL is hugely under represented in the toolset.

The exact same thing can be said for the project management discipline. Whether you use Agile Project Management, Agile Manifesto, Scrum, Scrumban, KanBan, waterfall, RUP, etc... Whatever you use should represent past, present, and future adoption of some project management process and tools. To hold one methodology or process above all others means that you do not know them as well as you think or you do not know your teams skills or needs in the project context. Adopt what works and don't get hung up on the glossary. Nothing is sacred except GSD (get shit done). You would be better off identifying when your process stops working and prepare to slide into some old or new process that might be a better fit.
[para] Sometimes you have to fire the rockstar for the sake of the project or the team-- Debugging The Development Process

Final words of advice.  As someone who worked for a payment processor when it was a startup and before it was acquired... it was a startup first and a technology company second... contrary to the executive whitepaper that had everyone believing it was a tech company. The only thing that we did that was cutting edge was implement some tools in Java and even that was block and tackle.  Everything else was VB, SQL, ColdFusion, and shrink wrapped Microsoft tools.
If you want to refer to yourself as a technology company then you are going to be on the leading edge of the upcoming tech ... and you gotta be prepared to fail in dramatic fashion.

But if you want to be a leader in your market then describe yourself as such. I would have described us as a "highly customizable boutique payment processor". Finally, when you brand your company as "high tech" you are going to pay more for everything. Specially programmer salaries. So pick technologies that are going to get you to market with few bugs with some basic ability to scale. Plan to make scale a hardware and devops problem and not dev.
Even a billion or trillion monkeys banging away on keyboards might have a remote possibility of producing the ultimate scalable web property but I doubt it will happen in my lifetime. So find other ways than writing code to scale your business.

[Updated 2012-07-21] I decided to add one final thought. Many successful businesses that scale tend to use a variety of languages. In no particular order they use everything from Ruby, Rails, Python, Django, Perl, Java, C, C++, .NET... but you never hear them crying about scale or using the latest language of the day... with one exception when FaceBook and Amazon declared that they separately implemented a chat server in erlang. To me that was just to generate press and possibly attract some rockstars. (If you really want to scale you need this guy or the message but your rank-n-file web programmer is not going to function at this level)


Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…