coder . cl

If you drive a company and his main business is development as service, have you ever thought on building products?. If you cannot cover the real cost of building a product with your current utilities and you have a well known market where to sell the product, you can start searching for investment, because you have several options to start building a product. You already know developers that you know that can do the product, you already know the market, and you just need to think a little bit more on the product to start building it, and start searching for investment. If you are not capable of do something as searching for investment, you are not probably good enough to make business. There is a related post that I loved, which also I am using as guide to answer many questions related to similar communications that I receive, which is entitled “Dear Programmer, I have an idea”, where the developer as final answer has four key points to review before asking for help on building a project, where he answers “So, either you need to:”

As you know I am working on an Industrial Control System — ICS/DCS to be more specific — and this system requires a task schedule to activate some pumps with a very strict calendar, monitoring the amount of liquid that has been passed through the valve, and it should allow manual operations, interrupting the automatic operation of that node on the plant. This seems to be difficult to implement, as I wrote in past posts, we are using a priority queue that contains task requests, where every priority is entirely dynamic, and dependent on the state of the current state machine that is being executed according to the operation request.

I think that this is a not so hard to solve question. The main reason why a developer is a good developer is «his interest on programming». A good developer always has a great interest in programming, so probably he will write a blog on programming, he will have a Github or Sourceforge account with his own projects, or even he will be participating on some open source project or programming forum — like StackOverflow — where you can appreciate his activity. If not, he will have his own side projects and he will be able to show you some demo on his computer using some application like Skype or TeamViewer, and he will be able to show his capacity with that side project. Another option is to send you a sample source code file, where both of you must keep the secret. Finally on the interview, you can challenge him to solve a programming problem, where he must prove his capacity with some simple task, like using an algorithm to solve a very specific problem.

The Presentation-Abstraction-Control architectural pattern is widely used. I prefer this pattern over other patterns like Model-View-Controller, because it does not lack third party component integration and allows better decoupling of components. «The abstraction component retrieves and processes the data, the presentation component formats the visual and audio presentation of data, and the control component handles things such as the flow of control and communication between the other two components». As you see it has three main layers, as MVC does, but this pattern allows integration of third party components and it is not limited to database models. Think on such applications using third party APIs, where you are not using a Model, ideally you are designing an abstraction to that API to be integrated in your application. Here the PAC patter fits much better than MVC.

A component in an object oriented system is a modular part of the system, where it has required and provided interfaces. On any system design each component should preserve its atomicity, without overloading its functionalities. This means that every component should have a unique set of interfaces to provide and a unique set of interfaces to request from its environment, avoiding duplication and providing the proper reusability. Non atomic components are not so reusable as atomic ones, because they cannot be connected in other tasks. For example if you have an LDAP interface and you want to send SMS notifications to mobile numbers on the directory, you should not plug the SMS notification into the LDAP component, it should be another separate component.

Where I work we are using code reviews, so each developer as peer is reviewing the code of another developer, using a review cycle where each review session is made to any different member of the team. All reviews are done in the team as peers, making the team responsible about the code that is sent to the QA stage. This help us to detect errors that cannot be seen by the programmer that owns a task, because is hard to see our own programming mistakes, and the team knowledge is balanced incrementally on each review. We are using Atlassian FishEye for code reviews, and we comment each commit when it is required, with internet links to well known bugs, documentation and papers, documenting each comment. Each team member knows about their peer programming tasks and how those tasks will affect his own tasks, and due to the system complexity we must avoid as much programming errors as we can — usually we do not send code with bugs to QA and we are constantly passing all tests.

There are some myths about programming and development methodologies. Among several of those myths, the one that makes laugh a lot is that one that claims that “you do not need skilled programmers to build successful software”. I really cannot imagine a team of non skilled programmers doing a successful application. Most myths are claiming that “the used methodology and management is more important than having good programmers”. Then CMMI, Agile, and several points of view about developing applications and systems are applied daily in software development. But more than the methodology itself, the fact that communications and skilled programmers are making great teams, cannot be denied.