My set of rules on handling projects and jobs related to programming are mainly related to payment methods, rates, methodologies and who is hiring me. So, non serious proposals are not handled by me. If you come telling me that you need a web page, just forget hiring me, I will not attend you, because I develop applications, not web pages.

refuse fixed price projects

Every software project without a well defined specification and clear requirements, is subject of changes, handling fixed price project is subject of spending unpaid work hours. So, my rates are monthly and hourly, depending on how is agreed the payment method. Fixed price projects which does not have a very consistent specification and requirements, will not be handled.

refuse projects with the wrong technology

As PHP projects, they will be refused. I cannot handle projects that cannot be properly integrated with other tools and languages that do not have strictly necessary tools like static analyzers and style checkers. PHP, Node JS and similar ones which has that kind of lacks, will not be accepted.

refuse projects where I did not made the estimation

Every software where I did not have made the estimation will be refused, I cannot handle projects where the estimation is not subject of concise methodologies like PERT. So, your compromise is not my compromise if you have made the estimation.

refuse projects without version control

Every project where you are not using version control, will be refused. I cannot stay sending tarballs with my code, creating messy products, everything should be properly branched and tagged on each milestone.

refuse projects without issue tracking

Every project should be using issue tracking software, agile or not, but I need that kind of tools to track each development stage, where everything should be clearly specified.

refuse projects without continuous integration

I cannot work with projects where you are not properly checking the code. The code should stay clean from its origin, with the proper style and avoiding common errors.

do not work with novice programmers

I do not work with novice programmers which are not capable to read a specification and they are not able to handle some basic stuff, like server configuration, command line tools, server administration, and the proper knowledge of the environment where are you working. If you want me as tutor or mentor, just hire me as tutor or mentor, it is a separate job.

You must have all those points in mind before hiring me or calling me for a project proposal. Those rules were created due to some failed project — two to be more precise.

© dmw for coder . cl, 2012. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

The most common job position in the last decade in software development is the Web Development. Almost everyone wants a Web Application, something that can run on a browser, without doing too much effort porting an application to desktop applications and similar stuff. So, most software development contracts are based on the Web. If you study something related to Informatics Engineering or Computer Science related topics, you cannot expect that they will prepare you for an immediate job position, and even you cannot expect that you will finish studying that career knowing everything related to it. Studying a career has the intention to get the basic knowledge on certain subject, enough to understand books that will bring you the proper expertise on that subject. Then you can do an MSc and you will be an expert on a small subset of topics covered by your career, also you can do a PhD, and you will be an expert discovering new stuff on a very specific subject of interest. You can read this wonderful article entitled «The illustrated guide to a Ph.D.» and you will see what I am referring to.

But if you do your stuff without interests, you will not learn, and you cannot drag any guilty to your environment about not learning enough to reach a good level. Everything is subject of interests, getting a graduate level on any career is not subject of decorating your room with a nice diploma, or showing a good position in your resume.

So, if you decide to get employed as Software Engineer on a Web Developer role, at least I am expecting from you that you will be able to read the Hypertext Transfer Protocol Specification and solve almost anything related to that protocol. A small team in one of those companies was working with a very specific service, mounted over HTTP/1.0 over a standard Apache Tomcat server. Rather than using SOAP or similar protocols, the service was working with HTTP POST parameters, and returning XML as content response. But they were stuck two days trying to solve a small problem. The HTTP client library that they were using was keeping the connections open and not closed, leaving many HTTP connections open on subsequent requests. If you know a little about browsers, probably you know that they are using — almost all of them — Keep-Alive connections. So, if you want to research what makes an HTTP client to use Keep-Alive connections, you should start searching for keep-alive and negotiation keywords over the document.

An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token “close” was sent in the request. If the server chooses to close the connection immediately after sending the response, it SHOULD send a Connection header including the connection-token close. [Hypertext Transfer Protocol -- HTTP/1.1, Section 8.1.2.1 Negotiation, first paragraph]

So, the right header to search for is Connection, which controls the HTTP/1.1 behaviour during the protocol negotiation. This is not CURL, which uses a closing connection negotiation due to its nature, which is not the nature of a common HTTP client which uses the standard specification.

HTTP/1.1 defines the “close” connection option for the sender to signal that the connection will be closed after completion of the response. [Hypertext Transfer Protocol -- HTTP/1.1, Section 14.10 Connection]

Finally, took me two hours to solve the problem reading the HTTP client library documentation and the HTTP/1.0 specification. The previous hack of destroying the client instance to avoid open connections was removed and the client library started its works using the proper standard behaviour. So, everything is subject of interest. The server was working with the right behaviour, not as some team members were thinking about bugs on the server. All those headaches were subject of a lack of interest on the issues to be solved. I just imagined how many lines of code were dropped and inserted trying to reach the proper solution guessing which API call would close the connection, trying to use many API calls, and just one extra line of code has solved the problem.

httpRequest.setHeader("Connection", "close");

Getting confused if you are under pressure is natural, I accept that. Also I accept that here in Chile being a programmer — now called Software Engineer — is not one of the most coolest job positions on the market. It will never will be well paid as manager position. But the lack of interest is not subject of where did you have studied. Probably making a complex career which requires reasoning, reading and effort, is something boring with pressure and not well paid job positions is causing that lack of interest, where most Software Engineers do not work on that job position for a long time. And this problem is not subject to be treated on a classroom, they just will bring you the basis. Reading and enhancing skills is your own responsibility.

© dmw for coder . cl, 2012. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

Without skilled people, and people with the proper domain knowledge about the project, it can fail on any stage of the development process. A project manager who is not able to specify the goals of the project cannot lead it. An analyst who is not able to describe — both technically and functionally — the project specification, will not be able to communicate the project objectives. A software QA who is not capable to describe a problem technically will not be able to communicate software bugs, and so on.

Too many projects fail or suffer because the team members are not the best for the job. Many project managers approach functional managers with requests for personnel without indicating the specific individuals she would like to have on the team. The most important skill of a successful project manager is the ability to negotiate. Considering that the project manager generally must negotiate for everything — budget, personnel, capital equipment, more time, and so on — it is not surprising that the more successful ones have highly developed negotiating skills. To ensure that the project team is composed of the best talent, the project manager must approach functional management and request specific individuals. The individuals requested may not be available to work on the project, but having asked for them by name immediately establishes the experience, education, and capability level the project manager needs. So, rather than supplying someone who happens to be available at the moment, the functional manager is more likely to attempt to replace the requested individual with someone who has as good or better qualifications.

[James Taylor, «Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives»]

Is quite different a bug report that indicates a bug as «The edit quote form is sending the POST request twice invalidating the CSRF token» than «The form fails with double click». The first one is very clear, the second one is obfuscated, hard to reproduce and just indicates what a five years old boy can say. So, you need a good QA, someone with the proper domain knowledge. Also you need skilled project managers, with the proper domain knowledge too. Someone that is not able to measure how much work is required to implement a change on the project, will not be able to negotiate the proper budget and price for that change, increasing the project cost. Someone that has stated «I have sold a CRM based on WordPress to be built in two months» is clearly a bad project manager without the proper domain knowledge.

I will leave you some open questions: «How often do you need to make overtime?», «How often you must be pressured to meet the schedule», «How repeatedly you need to close re-opened issues in your issue tracking software?», «How many times your overtime is not paid because it is being devaluated?», «How many times your project manager is not able to re-negotiate the project price, lowering your budget?». There are many questions that you should be asking yourself. Probably you are not on the best place to work as you think…

© dmw for coder . cl, 2012. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

I think that there are two important elements that are making the project value being much higher than the original value on any software development project, where both the customer and the employer wants to reduce the cost of producing that software. The first one is the amount of changes made on the software piece, and the second one is the amount of bugs introduced in the software piece. Among other stuff which is not being applied on many software projects like change management and impact analysis. Where the impact analysis is reduced to a mere functional feature opinion in most cases and change management is reduced to overtime work hours to meet the project schedule. Also the number of bugs on any software project can be directly associated with the number of changes that suffers that project.

The customer once gets the project budget, usually he does not want to change the budget if it is increasing the project cost, mainly if he is using the Spanish Theory to manage the project. So, management on those cases is reduced to some kind of political speaking skills rather than well measured and driven project, with the leading word «compromise» in most managers speeches and project leaders speeches. But you must be blind to avoid looking at that «compromise» as non-reciprocal one.

Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people’s backs.

Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).

The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

[Tom Demarco, Timothy Lister. «Peopleware: Productive Projects and Teams (Second Edition)»]

So, you must think twice when using the word resource to refer to your employees as replaceable mechanical nuts in your money-making-software-production-machine, because someone with experience knows that many of them are not replaceable and they are not mere mechanical nuts to be called resources. Have a look on successful companies — mainly how they treat their employees and they retain their employees — and ask also if the term to refer to them is resource. Every time that I listen the word resource to refer to co-workers, I only see blind people…

© dmw for coder . cl, 2012. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

An example of a good placed Unix system is Mac OS X, it has several command line tools to automate the operating system and make it friendly and its native development environment called X Code is very easy to acquire, without too much problems. It is a real programmer environment. Flexible enough to be customized, with various tools that allows you to program the environment, automate tasks and make life really more easier. For example while I’m programming and I want to seek source code with log lines, I use a single command line pipe to filter log messages, as follows.

$ find . -type f -name '*.py' -exec grep -nHi 'l.debug' {} ; | sed '/exc/d;'

On Windows and similar operating systems, which are specially made for users, rather than developers, I feel really truncated because I cannot do stuff like that. So, I become less productive under Windows and I hate it. Things that should be solved quickly with few command line and editor hooks — like Emacs provides me for editing automation — are delayed under Windows because it does not support that kind of stuff. What’s better than having an editor with an embedded Lisp interpreter? What’s better than having Perl and Awk among a lot of command line tools that allows me to automate any task that I want?

The same happens on its browser. Internet Explorer does not have enough tools for Web Development like others have. On Firefox and Google Chrome we have very nice development tools, allowing us to create amazing DHTML / AJAX based applications, among other stuff like building amazing HTML 5 and WebGL applications. I find really frustrating any work made under Internet Explorer. If you want to debug a simple JavaScript implementation — which is not really JavaScript under windows and it is dialect called JScript — you need to launch a whale called Visual Studio. So, to become productive developing Internet Explorer applications, you must pay for something that will be used with a 10% of its capacity, including the licensing cost of Visual Studio.

So, for me Windows, Internet Explorer, and related technologies are a mere gaming console, rather than a developer friendly environment. That is why I dislike using Windows and developing systems for that operating system, because it is poor, overfilled with useless ornaments rather than useful tools.

© dmw for coder . cl, 2012. | Permalink | One comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

How many times did you hear the words «I cannot pay you more because this is the market salary». Then you start looking other job positions, and you want to leave the programming career because it requires effort, you must think all day, and usually you must do overtime because you must solve requirements which are not managed properly — handled by mediocre project managers that allows the customer to request changes in the last hour — and are allowed to be handled as urgent requirements always because they want a cheaper development.

Usually those companies are requesting low profile programmers too. People that cannot handle complex programming problems. They are cheaper. So, you must not expect smart people working for those companies, and even you will not be able to say «show me the code», because they do not have a real interest on programming. Usually those companies are a trampoline to reach a higher positions as project manager, software architect and department manager, so there is no real interest on doing software. There is a big difference between someone that enjoys programming and someone that does not program, and usually those programmers that are seeking a higher position are falling in the same game, and allowing those «last minute super requirement that will change the world» to be implemented.

And you slowly are getting bored of programming because your environment, or maybe your company is not as good as it is described in newspapers, and it seems that you feel as slave. But it is natural, because your company is selling cheaper development and is not capable to sell good development, so the economics of your company is not driven by good managers. Optimization is not the approach of your company, they are using maximizations, delivering projects in less time that it is really required, making your work a daily torture programming overtime and meeting milestones with less time that a software piece really needs. So, there are two options, your project manager is a really bad project manager because he cannot manage requirements, or your company is a bad company because they cannot manage requirements.

If every project is urgent and should be solved as soon as possible, the fact that your milestones and schedule have the wrong estimation is real as the fact that your project managers are only thinking on the bank check at the end of the month.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

You should know that including new developers in any project requires developers with a very quick learning curve, skilled reading documentation and reading the specifications provided by the team leader. Someone skilled managing projects is able to negotiate the schedule to finish the project with well planned milestones and deliverables. He should be able to stop any requirement change, or should be able to move the delivery date on any strong requirement change and negotiate a new price for the project because the final product requirement are changing.

In some manner, that is why I am currently charging worked hours instead of charging fixed price on any project that I handle. Usually project managers are not able to manage requirements, falling in overtime requests, with a strong lack of negotiation skills. So, for those projects with fixed price I say «sorry, but I cannot work for free». Mainly when software is subject to many changes, rather than physical products, where you cannot change the design many times as you want if you are not able to pay sequential builds of the product. So, on any requirement change, if the project price remains intact, I can clearly see that the project manager is not good enough and skilled enough to generate earnings for the company, with subsequent implication that I will not receive more retribution for doing an extra effort on building that project. So, «no compensation, no more work».

Receiving a compensation on any additional work, should be a must for any project manager. Otherwise they can start searching for another job, or you must simply leave the company — as I have done on my last work as employee — because you must not work underpaid, and you must not work doing extra effort if that effort is not compensated. So, «lift up the hearts, drag down the pants» do not works with me. I cannot work with project managers that keep saying «the customer has the true, even if they are not technically skilled».

a short illustrating story

I was working for a very big — I really mean very big — social organization, an international organization. Everything was going fine I think, deliverables were really delivered at time, and I was doing telecommuting. The project was based on PHP. Along the time, I have clearly detected that most people working on that Big Social Organization was not skilled as I was expecting from an organization like that.

For me, as a good developer, I have no problems to use version control systems, including continuous integration systems, because they allow me and my project managers to measure the real effort of coding. But that big organization kept using tarballs to send project updates. That big organization was not able to configure the server properly using written instructions — was that big organization capable to read technical documentation? — seems that they did not read the documentation. Me as freelancer, who can work with C, C++, Lisp, Haskell, Python, Perl, PHP5, C Sharp, Java and Visual Basic .NET, cannot have any excuses to do self-taught learning among reading documentation and reading Math books and similar stuff.

A was in front of people without good technical knowledge, so they were not capable to measure effort related to software development. The system was made from the beginning using object oriented programming, based on a LAMP stack and Zend Framework. From one day to another, we received the requirement to build everything from zero, using a procedural approach, without objects and classes, and everything should be finished in one month. So, migrating an entire platform from OOP approach to procedural and structured programming approach was not measured correctly. As result of my denial to rebuild the application, the payment was cancelled, a very «carrot and stick» approach on work.

Because payments were made using the famous «salary based on the market» for PHP5 development I was not receiving a good compensation as Java, C, C++ and Python developer, so I was considering the job only as a social benefit. That was great, but making less attractive the job position just because that big organization was having a big name and was able to cancel the payment because the project manager has changed his mind about how the project should be made was very bad decision I think. So, «no compensation, no more work», no matter how big is your company. Among the inherent problems that carry the lack of using version control systems, continuous integration systems and the proper coding style normative, without the proper knowledge of the best programming practices.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

Certainly, one of the worst enemies of programmers is getting stuck on a programming problem. But there are other well known enemies, like bad specifications and badly taken requirements, all of them can make a programmer to work twice, mainly once the programmer thinks that the problem is solved. Any of those errors are very de-motivational on any circumstances.

Personally, to boost my productivity as programmer, I do a previous analysis before I start my programming tasks for my workday. You can distinguish two types of tasks, those where you know exactly how to solve some problem, and those tasks where you don’t know how to solve the problem. There are also two subgroups, those tasks that are easy to complete once you know how to solve them, and those tasks that are not easy to complete, even if you know the solution or not.

Problem Levels

To get things done, I use a very simple schedule. I treat all problems that are on the group B (known-hard) first, then I solve all problems that are on the group C (unkonwn-easy), both tasks in the morning. Then I solve all problems on the group B (known-easy) after the lunch, and finally I do not solve those problems on the group D (unknown-hard), instead I do the required research to complete those tasks the next day, very early with a fresh mind, so they become group B (known-hard) or A (known-easy) problems.

Problem Schedule

So, all unknown-hard problems, will become known-hard the next day. Leaving the last hours of the workday to do research and doing theoretical solutions instead of coding, will bring you a more relaxed day ending, allowing you to progressively leave the coding activity. I think that is bad to be the complete day programming, you must do other activities, like reading. Organising problems according to its complexity brings me more productivity than doing problems sequentially.

If you are able to organize your schedule with the proper sequence, probably you will reach your better performance, because you will be using the proper energy to solve those problems, rather than doing tasks in sequential order, you will assign the priority according to its difficulty and the hour of the day to meet the best concentration regarding the problem to solve.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

Such size of contribution is clearly visible on most operating systems today. With Unix he started the time sharing era, where all desktop operating systems and most servers that are running today can run multiple tasks with the sensation of plain and transparent execution. Also, most operating systems are written on its core base in the C programming language, which is a common language for system programming, a well known friend on system programming tasks.

Mac OS X was born on the basis of a Berkeley Software Distribution operating system. Its kernel is a combination of the XNU/BSD and FreeBSD, where the XNU micro-kernel was adopted using the FreeBSD kernel services, and that kernel was called Darwin. The base system — most command line utilities — of the Mac OS X, iOS and related operating systems, are made on top of the FreeBSD operating system. And FreeBSD was born from 4.4BSD, and the father of the 4.4BSD operating system was UNIX. So, it is not strange to find utilities with a long history.

Also, the basis of the NeXT operating system is a BSD variant. What was adopted by the current Mac OS X from NeXT?, just the UI API calls. The complete UI API calls and classes defined in the Objective-C programming language — an object-based variant of the C programming language, and hybrid between C and Smalltalk — are made on top of the OpenStep standard, which is a variant and direct descendant of the NeXT Step UI API.

So, many ideas are not new. I think that the great inventor was Dennis Ritchie, and Steve Jobs was good orchestrating technologies, using the right technology on the right place.

What I want to rescue from this, is the fact that if you want a successful company, you must work as team. A good inventor cannot work alone if he does not know where to place a technology of his invention. A good CEO or manager cannot work alone if he does not know how to build a technology. So, both and working as team are required to successful build a good technology. If you are planning a company, associate with a good co-founder CTO.

Also, I was watching on the TV an interview related to Steve Jobs to a well known twitter user here in Chile [@stark], and I was really disappointed with how wrong was the information provided by that guy.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

tl;dr

No matter the process, without motivation and the right methodology, you will fall in mistakes.

about the process

At one side, there were rigorous process and several structured documents to fill on each process that was build as key step on the development process. Some people working on those companies can be labelled a NNPP, or bad programmers. But not by a lack of knowledge, instead of that there was a lack of motivation, which is more dangerous than lack of knowledge. That was leading some developers to commit programming mistakes, and then leading others developers to fall in monkey patching, delivering those well structured documents with non-technical descriptions about what they were doing, but a product quality that can be delivered by programmers that do not have more than two years of experience.

Many of those de-motivated programmers were expecting to be ascended to project managers or analysts, and similar roles, and they really were not wanting to program. So they were not enhancing their programming techniques, were not interested on enhancing their programming skills, and most delivered products were delivered late and with poor quality. Many times skilled programmers were assigned to do the required monkey patching to deliver the required products on their milestones, but the products were not really deliverable. I know that there still are a lot of bugs to fix. No matter how well defined, how good and how precise is your development process if you do have motivated programmers that really like to program.

Most successful companies have motivated programmers, people that really likes to learn and enhance their skill on this area. That segment is very small, so you must take care of your skilled programmers or they will leave you, searching for a company that really appreciate their skills. Those managers that have in mind only the process and have forgotten that they are working with humans, usually are derogatory with their developers. They have more faith in their process model rather than their programmers. They really forgot that the know-how is not held by the process, and cannot be hold there. No matter if you have a wide library filled with well documented how-to, the problems appear once you reach new problems to solve, and there is no documentation to supply solutions. Then you need people that can think and have enough knowledge to solve the problem.

You do not need to send your programmers to motivational talks or similar stuff. If you want to keep them in your company, you just need to be conscious about their motivation. Usually they like challenges, but not those where you pressure them to get things done where other programmers were not able to complete certain tasks. Nobody likes the monkey patching, so the best effort must be done early, not lately. You must put enough leadership in your development process to make all your programmers conscious about that. I am efficient in my programming tasks, but it is because I do my best effort early. My customers are happy with it. Obviously if you make huge changes in your project, like changing the database model and you want those changes for free, I will leave your project. I will not work for free, and I dislike those people that are doing that.

about the methodology

Currently I am using Scrum to handle the requirements through the backlog. Mainly because many of my customers are changing their requirements dynamically. On strict projects, where I must design algorithms or do some algorithm research — for example I have received a proposal for an algorithm design where apparently I must apply dynamic programming and some ranking techniques — usually the requirements are well defined from the start. But there is no human interaction on that algorithm design and the daemon that is supposed to build the rank and the index — probably I will use something similar to PageRank and MapReduce, mixed with some Levenshtein distance, Bayesian classifiers, linear classifiers, and related stuff. At the other side, where is required human interaction, probably there is a lot of input parameters that are changing in the forms that can fill the user, changing also the complete behaviour of the system, there is required a dynamic requirement management that can offer Scrum. With those changes also is required a re-estimation of milestones and project cost recalculation, or you will be working for free. So, it really depends on the product. If your customer is constantly changing requirements and you are using something rigorous like CMMI, you will fall in project loss, since you will spend more time filling documents and adjusting requirements, delivering specifications too late for your developers, mostly if you do not change your milestones.

So, your development process should be dynamically handled and use the right methodology with the right project and the right customer. You can be building a software specification for three months, but if you customer changes its own processes on those three months, that specification, the document that was written and the time spent on that, will be lost.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)