Hello, just a quick introduction, my name is Mark Deepwell, and I work for the best software company on the planet, Thirdi Software Inc.

I recently read Daniel Tenner’s blog post on How to recognise a good programmer, and I was curious to see if we do have good programmers according to his criteria.

First I thought about the passion each of us has for our job, and asked each member of the team if they love what they do, and in fact, I quickly found that each one of us here at Thirdi loves what we do.

Ivan likes the whole software development process, from requirements and design to the final high quality product. Stan enjoys solving programs with an elegant solution. Abe, our QA guy, is passionate about delivering the best possible software to our clients and is not satisfied with a product until it is bug free. Matt loves his job so much he says it doesn’t feel like he has a job anymore. And I enjoy creating what we call painless software, software that is simple, easy and straightforward to use.

From talking with the team, I learned that self-teaching is a pretty strong part of our culture. Stan, a Java programmer, learned PHP on his own for a new project and Ivan picked up the Zen Cart framework when he created an online store. Learning a new framework or technology is relatively easy, but being able to leverage it appropriately is a challenge. We don’t use the latest technology buzzword just because it’s the current hot item, but we would use it if the scenario were appropriate. Each of us are self learners because we enjoy it, and we can use the added skills to build better products.

Each of us has worked with a variety of technologies, from bash shell scripting, to JavaBeans, we have used a wide variety of tools and languages: Java, Ruby, Bash, C++, Hibernate, JV2, JV3, Struts, Perl, PHP, Symfony, JMS, Propel, Torque, SOAP, Lucene, and many more. This is just a subset of all the technologies and experiences various members of our team have gained.

Even for a new project each of us will be working on, we have decided that it will be built on Ruby on Rails, an up-and-coming web framework that we’ve been wanting to try.

Does Thirdi Software have good programmers? I believe we do, and the breadth of skill and experience we each bring to the table surprised me.

As a software developer, I always find it challenging to account for non-functional requirements while developing software. All software clients and project managers will tell us they want their software to be efficient, effective, fast, secure, scalable, maintainable (not restricted to codes), usable, and resilient. A lot of times (though not always), these constraints are vague, unquantifiable, and contradictory (for example, the most effective way of doing things may not necessarily be the fastest).

It is not uncommon for software developers (myself included), who have been programmed to think and work with logical, tangible, and quantifiable entities, to sweep these constraints under the rug until, one day they come back to haunt us. Yet I religiously believe these constraints, to some extent, can be implemented in the software. A lot of them can be accounted for during the design phase of development.

For example, we are 2 weeks into the Gamboozle Fantasy Sports project, and here are 3 non-functional constraints that stood out during the design phase.

1.      Potential Performance Deterioration As A result Of Data Growth. The way we decided to deal with this constraint was to implement an archive module, which is scheduled to migrate old data from some of the “bigger” tables to new tables. Ideally, a simple SQL INSERT.. SELECT statement will do the job. Since this archived data will still be accessed, we need a mechanism to identify which tables (current vs. archive, and if archive, which archive) the end-users are trying to access. A naming convention for these archive tables is needed too.

2.      Efficient Computation. As part of the business requirement, a number of aggregate values have to be displayed regularly to the end-users. Instead of computing these values on-the-fly, we decided to devise a calculate-once-display-often mechanism to help lighten the frequency of number crunching.

3.      Code Maintainability. Since this project involves PHP and JAVA components sharing the same database, there will definitely be some redundant code in the object-relation mapping (ORM) layer. We have decided to use Propel and Torque as the PHP and JAVA ORM layers respectively. Since Propel is ported from Torque, their XML database schema files are very similar. So we will be able to generate 1 common XML database schema file for both components. In this way, any modification to the database schema, for example, adding new columns, dropping existing columns, type change etc., can be easily propagated to both the PHP and JAVA ORM classes.