Sustain the Business or Build Good Software?

That shouldn’t even be a question. But it should me more than familiar to people who have been in decision-making roles in software companies. That includes developers. An officemate shared an article from Martin Fowler the other day:

It’s a great set of principles to build a software business on. I’d like to share a quote that caught my attention in particular.

“I remember Trevor Mather (our CEO) contrasting ThoughtWorks with his previous experience at Accenture. He commented that ThoughtWorks did a much better job of software delivery than Accenture, but clients were much happier with Accenture than with us.”

Martin points out that sometimes there’s a tension between sustaining your business, and software excellence. Devs would often find themselves facing a question of whether to compromise on the quality of the product they’re building in order to meet some immediate need of the business. In some cases that directly translates to client requests for the software your selling, or are asking you to build. Having to say no, or forcing clients to take another way because you know that that’s the right way (read: gives them the most value) can get you negative feedback.

I was originally going to post examples, but while typing it out I’ve realized that there’s no blanket answer for every situation. That tension exists. It’s good to know it’s there so that you could carefully weigh the trade-offs. Now you have to make that decision for yourself. It’s difficult, and I hope you have the experience to make that call correctly.

There are certainly business models who pay lip service to quality, and do make money out of it. Software-something-to-sell more than excellence. But I believe that all Software Engineers should give Software Excellence equal importance as having a sustainable business. Because, in the end, excellent software will do more than just sustain your business.

Adventures in POSTGRES: Lowercase Everything

So I’ve been trying to transition from using MSSQL to POSTGRES, and I’ve encountered a few bumps here and there.

One of the tutorials I was following recommended using the Chinook database (a handy test database which has set ups for multiple db providers) as a sandbox. The database uses the naming convention I’m familiar with which is UpperCamelCase for some db objects like tables and its columns. For other things like stored procedures or functions, it’s in LowerCamelCase. Imagine my shock when I ran a simple query to the table “Albums” in the default schema “public”.

[sql]select title from album[/sql]

I got served a

relation “album” does not exist

It turns out that if objects like table names are in UpperCamelCase, then you have to wrap them in quotes before POSTGRES understands what you’re actually trying to do, like so

[sql]select “Title” from “Album”[/sql]

So if you want to avoid all the pain and frustration of having to type in those extra double quotes every single time, keep your objects in lowercase.

[sql]create table artist(
id serial primary key,
title varchar(160) not null

The POSTGRES docs give good guidelines on this. I guess the convention is good in that it’s easier to type things everywhere, but I can just imagine how painful it would be to attempt to migrate an MSSQL database to POSTGRES later on.

As a bonus, not only did I learn about the casing problem, but I also learned that relations in “relational databases” had nothing to do with the lines drawn between tables we call “relationships”.

Book Review: Dreaming in Code

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent SoftwareDreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg
My rating: 5 of 5 stars

“Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large… If it doesn’t solve some fairly immediate need, it’s almost certainly overdesigned.” – Linus Torvalds, Linux Times, 2004

Life is complex. Trying to model even one real-life process into an ethereal tool will no doubt embody part of life’s complexity. But this isn’t immediately obvious to the optimistic programmer. A grand vision of building the-next-big-thing is enough to fuel one’s optimism and blind them to the fact that the-next-big-thing is like really, really big. This isn’t uncommon in the Software Industry where building things (small things) seem to not take as much time as other industries. Open an editor, write a few lines of code and you’ve got something on your screen unlike say a bridge where the first may take a few weeks or months after someone draws up the first draft (I have limited knowledge on bridge building so don’t quote me on this comparison). And when a programmer finds out that building software isn’t as easy as they thought it would be, they can’t help but wonder if there’s something they’re missing. And then they get a book like this and try to read about how other people are doing.

Your average pretentious software engineer might read the title of the book and think that “These must be some enterprise software engineers unlucky to be in one of those process heavy companies where they have to do some archaic process like waterfall or RUP. If only they’d done agile they wouldn’t be in this mess.” Surprisingly though, your average pretentious software engineer would be proven wrong as they find themselves in the shoes of the Chandler team. The team involved a lot of the brightest minds working on an open-source project with a huge budget that’s just enough to keep them going for more than 5 years. Depressingly enough they did go for more than 5 years. I’m very grateful to Mitch Kapor for giving the world a window into one of his most challenging projects. His openness and willingness to have this documented and shared just shows what kind of person he is.

The book itself is a fun read. It isn’t your computer science or management textbook nor is it your boring documentation of the Chandler team where the narrator jumps from one event to the next. Scott Rosenberg gives his readers a view of the conversations, meetings and other happenings inside the Chandler team’s office. From a programmer’s perspective, some events may even sound eerily familiar to their own encounters and conversations. I do appreciate his attempt at providing the occasional explanation of a principle or idea to the reader, sometimes even giving a short backstory at how that came to be. Some find that distracting, but I do find it helpful. This can even serve as a gateway to newbie software engineers trying to understand the world they work in and introducing them to some very helpful engineering principes while they’re at it. Though there are some concepts that he does seem hard pressed to explain in layman’s terms, but hey who doesn’t have to go through that challenge every once in a while? Concerning the book’s theme, one might get the impression that this book is one big what-not-to-do-when-building-software. There is much of that yes. We can benefit from other people’s hindsight, examples of which are when in early chapters/years they rebuilt much of what they could have reused from elsewhere. But some of those simply reflect the difficulty of building software. Where collaboration and figuring out how the team that builds the software works together and the direction they should take is a great deal important as actually building the software itself. There are other points in the project where taking a calculated risk does not mean that it stops being a risk such as the team’s investment against the web technologies of their time. There’s a lot to learn from every team. The team’s members themselves would no doubt have learned much from the experience. And readers of this book will find much to learn from them as well.

Great read. Learned a lot. Would recommend. 5 stars.

View all my reviews

This review was first posted on Goodreads


“Believe me”

There are waaaay to many things to think about. Overthinking shouldn’t even be my problem (I’ll go over overthinking in a separate post), given that we have so many things that compete, not just for our attention, but also our understanding of them.  Lourd de Veyra even said in his commencement speech just a few weeks ago, “nagtatampisaw tayo sa baha ng impormasyon” (We are floundering in the flood of information). I browse the internet on a regular basis. I get a bunch of articles on a daily basis coming from my feeds, facebook wall, links from friends and the like. I get my regular flood of information everyday. Now besides the fact that I struggle daily with trying not to drown and die from information overload, or the fact that my average-ish brain is struggling trying to take it all in, this made me realize that there was a bigger, more important problem that I had to address:

Which of these speak the truth?

Which beliefs and opinions should form the base for the principles that I will follow throughout my life? Which ones work? Which ones should I dismiss? And it’s not just the internet that trigger this kind of thinking for me. There’re the people around us that regularly exert their influence towards us, like those that come from your best friend for example, or those who you grew up with, like your family. The opinions and beliefs of these people add up and compete with the right to influence your own beliefs whether by suggestion, or straight-up imposing it on you, or by the person’s mere regular proximity to you that you slowly but surely pick up on what they believe as well. And there’s my own emotions, beliefs and biases that add to the mix. There’s the feeling of sympathy in certain situations, the occassional hipster-feel, the bias against certain people or events that affect what I believe.

I don’t know about everyone else but this gets me frustrated. This gets me really, really frustrated.. and bothered. I don’t know what to believe. Just recently, from my recent encounters with people (and the interwebz), I’ve had to question what I really believe about the following topics:

  • Grades matter, but should they really?
  • Is the Chief Justice guilty or is it just the President messing with us?
  • Will investing in a smartphone pay off and which smartphone brand has the promising future?
  • Is eating healthy worth it? What kind of healthy eating actually matters in the first place?
  • Is there a place in society for boyfriend-girlfriend relationships?
  • Tradition and culture are important in keeping one’s identity

These are opinions from various kinds of people from people I know, from people in the internet that I don’t know, people whose opinions I care about, or even people who don’t matter to me at all. They are many and some of them really matter, and choosing the wrong belief will lead to the eventual consequence. And with the sea of opinions and the fear of not knowing if the belief I’ll be picking will lead to a great amount of pain, I usually end up undecided on many matters.

This blog’s aim is to address that indecision. It will attempt to lay down in writing what I believe to be true so as to better understand what I myself believe about things. This blog is my own way of forcing myself to take a stand on beliefs that confound me. And may the Lord help me in this endeavour! Fortunately, in the sea of opinions and beliefs, in the case that the currents threaten to sweep me away from the truth, I can always cling to that one source of information that always has and always will contain only the absolute truth: the Bible, the word of God, breathed out by Him and profitable for teaching, reproof, correction and for training in righteousness. [1 Tim. 3:16] May His word be the foundation of whatever belief I will profess.  Now I am not perfect, and I know that I may end up misinterpreting or misrepresenting something or someone at some point, so I ask dear reader, if you may be so kind as to gently point me in the right direction. If I am in danger of misrepresenting God’s word, even more so, rebuke me Christian brother or sister. And I pray that whatever writing may be found here, may it be written with great care and all of it end up in bringing glory to God’s name.