Process

I’ve found a bug! Who to blame?

Despite that blame culture serve no benefit to the company, many companies still have this culture. Moreover, it is stupider to put a blame for bugs happened in software. Simply said, that’s because bugs happen, and the possibility of a bug is close to infinite.

Many times, many parties responsible for bugs in production

Let’s say that we use the following SDLC: requirement, analysis, design, develop, test, implement, maintenance. Now let’s see which responsibility can be held in each phases for each parties.

Requirement

The requirement given by user is ambiguous, has multiple meaning or the worst, he/she is wrong when giving the requirement. Next, the meeting PIC (person in charge) is doing mistake during passing the requirement through the analyst and programmer.

Analysis

The analyst doing a mistake during interpreting the user requirement. The analyst is mistaken during communicating the analysis and requirement through the programmer.

Development

Many-many things can happen during development. Wrong logic condition, wrong parameter assignment, etc. In short, the code is wrong.

Testing

The test case is very lacking compared to the complexity of the project and environment deployed. The case is testing wrong things. The test case resulting in false positive.

Implementation

Incorrect publish parameter. Incorrect deployment tools configuration. Production environment not tested beforehand. Production environment (OS, etc) is different with testing environment, and the code has environment-dependencies. Worse if the publishing done manually.

Maintenance

Internal support team inserting data with format that is not tested (whitespace characters). Some script being executed without tested. No change management for software correction, which causing the developers can directly push file to server. Some maintenance activity (backup, index rebuilding) causing anomaly and incorrect results. User trying to break the system.User input data with unsupported format.

Other causes

Requirement change mid-development. Some requirement break / not compatible with other requirement. Development time being shortened to meet earlier shipping date. Natural disaster causing loss in development time, but no schedule adjustment.

Bugs caused by many factors

Despite code / logic error, many other things can cause bug to an application. For example:

  • compiler / interpreter error – very rare cases though
  • flawed server configuration / installation
  • OS-level bug
  • Bug caused by different configuration in different environment
  • Error caused by cosmic rays
  • Y2k error – year 2000 problem
  • Network-related error
  • Incorrect data / format
  • Not-printable characters input

And there are many-many more.

Conclusion – now, who I can blame for that?

It’s best to not blame anyone for bugs / error happened in a software. Entire team / company should take responsibility for the error (even user as well). What you need to do is, to find the root cause, fix the software and find a way so the same mistake / error won’t happen in the future.

Advertisements
A standard mouse, good for teaching though

Important factor when giving lesson

I get the idea for this article after reading Testivus on Test Coverage story. In this story, three programmers asked Testivus about proper percentage of test coverage. Testivus gives three different answer and every answer depends on skill level / knowledge and attitude of the programmer. The same can be applied to every lesson that you, or anyone when teaching.

Example

Let’s take a situation, where you are teaching newcomers about programming. First, you teach them about variable, data type then if-else, function and so on. You will try to arrange the topics and course material as easy and as non-technical as possible. Later on after several meeting, you can move to deeper and more technical topic.

Absolutely you won’t mention about interface, clean code, architecture, dependency injection, CQRS or any advanced-level topics during the first course. They don’t know what those topics are about. They won’t get anything beneficial from those topics. It is same as a programmer attending a seminar about newly founded medicine which can cure cancer, presented by researchers targeting senior doctors.

You don’t teach any advanced topics during first course for newcomers

Why so

Man 1: hey, YYMM’s stock is on golden cross today!
Man 2: Have you see the 60 days MACD? It haven’t touch the support yet!

Are you an investor? Or have you do stock once or twice? If you do, then you will know what the conversation above is about. Assuming that you don’t know anything about stock, what is your reaction when I tell you to buy a stock because it’s on golden cross today? What knowledge do you get from that?

Nothing. You don’t even know what a stock is about. You don’t even know about the stock basics yet. The basics is included as: stock unit, how to buy it, how to sell, how the price is formed, open/close/high/low price, closed market, closed time buy, etc. After that you need to learn about resistant and support, then graph, then you are approaching the more advanced concept such as fair value and reading quarterly financial statement.

Now let’s say that you already learned the basic, then suddenly you attend a seminar led by George Soros about how to do a 3 months projection of a stock value based on current financial statement. I guarantee that you either be confused and get nothing, or at max you only get the minimum value from it.

Now let’s say that instead of that seminar, you attend a local financial institute seminar about how to do cut loss and planning for cut loss. You already know the basics and that topic is not too far from the basic. You will understand what the seminar is about and get full benefit / knowledge from it.

When attending a wrong course, you will be confused and get nothing. However when attending a right one, you will understand it and get full benefit

The case in IT / Programming

“How to build an e-commerce with PHP, mysql and laravel for beginner”. When I ask for suggestion about what topic should I bring for newcomer, many colleague suggested that topic. Then as usual, I spend 15-30 minutes explaining why it doesn’t work. Every time.

This is also the basis for my decision to use javascript as programming language for newcomer. Weakly typed, interpreted, support procedural and multiplatform. They don’t need to do variable declaration, initialization, type casting (conversion still exists, though), directly run the code without compilation, and no need to learn about object oriented or classes and the likes. With this, I can teach how programming works and they can immediately learn about the concept of programming.

The software requirement is negligible. With a programmed environment, for example this jsfiddle: https://jsfiddle.net/fendy3002/1embueho/, someone can begin programming anywhere anytime. So far I only find one weakness and that is to receive input from user, you will need to learn html first. That’s some big sidetracking I must say.

I use javascript as programming language for newcomer because it is weakly typed, interpreted, support procedural and multiplatform

Conclusion

To ensure that the topic you bring in a course can be learned effectively and beneficial, you need to know the skill / knowledge level of said attendance.

 

Which attitude for hire?

In management world, you will often hear the following quote:

hire for attitude train for skills

The quote is good and hit the point. However even after you agree that attitude is better than skills for hiring people, knowing which “attitude” that are being mentioned in the quote is important. I will say that, without knowing the attitude that is mentioned in the quote, you better hire for skills instead.

In this article, I’ll use many references from Pawel Brodzinski. His writing is insightful and he is good at management. Moreover, he also had written one article titled “Why I Genuinely Want To Work With You“, a very similar with this one.

The essential attitude : Honest, open handed and cheerful

Essential attitude are useful in any kind of job.

For me, the very essential attitude, required and isn’t negotiable is honesty. A person I want to work with, or hire must be a honest person. Brodzinski also say that in business, the trust isn’t measurable. For me, honesty is the most important part in building trust. Dishonest person won’t make a great partner, and they will even make me work under suspicion and making me take extra step to prevent them stabbing me in the back.

The second essential attitude is open handed and willing to help, If they are willing to help me, I will do the same and am willing to help them. No matter how skilled someone is, if they are not willing to help, their ability won’t be much of use.

Last is cheerful. Why cheerful? A cheerful person will bring positive energy to workplace. They will brighten other employees and they can get more motivation and less stressed. In front-desk jobs, a cheerful person will be more liked by customers rather than a gloomy one. You wouldn’t want to work with a gloomy person, right? Worse if that gloomy person is your supervisor.

Note: There may be several disagreement about those three attitudes can be useful in any job. Ex: cheerful factory worker or honest sales. It is conditional though and can be interpreted differently. Ex: the sales is honest to the company and only do small lies to the customer, or cheerful factory worker can be serious at working and fun at break time.

The job-supporting attitude

Different job need different supporting attitude. That’s why you cannot determine that an attitude will be useful for any line of job, even if the attitude is positive one. For example: a manager or CEO will need to have innovative and creative thinking attitude, while a factory worker need not to have that attitude. A non-innovative or non-creative factory worker is better than innovative one, because they can follow order and won’t complain about the current system. It’s cruel I know, but it’s what the business needs.

The same is applied with the so-called good attitude: “hard worker” and “can work under pressure”. Both of them has very specific appliances and not all line of jobs benefit from them. Managers that is “hard worker” usually cannot manage well. They often do the work themselves and leading to micromanagement. If not, they usually prefer hard-worker staff, resulting in overtime, reduced employee happiness and reduced employee creativity and problem solving skill.

In programming world, they don’t need the “can work under pressure” attitude while most company stated that they need programmer with that kind of attitude. I don’t really understand the reasoning behind it. Unless the software they are developing is used in military, nuclear plants, airplanes or anything that can involve life beings, there won’t be any meaningful pressure.

Michelangelo, talent is cheap, dedication is costly!
– Bertoldo de Giovanni

For every job that need skill refinery such as smiting, music, crafting to even programming, dedication is a must-have trait. They need to be dedicated to their job, doing and doing the same thing countless time, refining they skills anytime to make them able to provide masterpieces.

Conclusion

There are essential attitudes, where the attitudes are useful in any line of job and the other attitudes are job-specifics. Knowing which attitudes to look for is as important as knowing that hiring for attitude is better than hiring for skills. When you are mistakenly looking for the wrong attitude required, you are hiring the bad employee.

Custom apps IT Solution vs Product Developer

Last night I was being interviewed at one IT solution. The interview goes normal, with questions technically and personally. However I feel that the topic of question is different from the last time I had interview (around 2 weeks ago). Long story short, this interview asks more about technical skills and ability of using tools, while at the last interview the topic is leaning more to design, architecture, security and performance.

Custom IT solution is doing the hard work

I’m sorry to say and if this phrase is very harsh to you, but if you are working at custom IT solution, it means that you are being expected to do hard works. The client does not expecting you a good quality product. They expect you to work under their order and develop what they want. You are being valued by how hard you work, not by the product you produced (well the product also being valued, but not as much as your hard work).

I may sound narrow minded, but that is what happen in majority of custom IT Solution companies. Maybe not all (if any), but at least most of them do like that, at least at my country. And no, I don’t say that the practice is bad, or delivered bad-quality product is a sin for those company. It is just a nature of the company, enhanced by clueless leader about IT world. Moreover, the business nature of custom IT solution tend to bring the company into that path.

Faster delivery = more revenue

It is true for all IT solution that faster delivery = more revenue, because faster delivery means more project to handle and it means more income. However the way they do to improve delivery time is wrong. Usually they cut testing time and encourage overtime (worse, unpaid). It resulting in fast, low quality product. Fast, cheap, good, pick two. Usually they pick the fast and cheap one.

Less self improvement

Self improvement (better design, better framework, better developed component, code review, test units, etc) is third priority inside those company. Product delivery takes number one, while customer support takes second. It is because self improvement is seen as expense (manpower and time) and has invisible/indirect benefit. Training and conference does not fall into self improvement though, because it is tightly required to development. Try to learn kaizen.

Even if the company apply self-improvement, it will be driven and handled from top levels, rendering your involvement useless.

Bad documentation

Because you can support and train the customer directly in such big time span (morning to night), it makes documentation less required. Moreover writing a good documentation, and update it every changes will require big effort.

No idea will bloom

Any sprouting idea won’t bloom. Because everything is made by customer request, the company does not need good, fresh idea. They just need a good worker and constructor. Moreover, idea will be seen as hindrance, costly and too much effort to apply.

What about product developer?

If the company developed a product and live by it, the mind set will be different. I don’t say all product developer like that, but at least the successful one does.

Higher quality = more revenue & less cost

Am I drunk that I write something like that? No, I’m not drunk. In product developer company, higher quality product will increase customer satisfaction, resulting in good testimony and recommendation, then resulting in increased sales, means more revenue.

But isn’t higher quality means longer development time and higher cost? Why it can become less cost? It is indeed higher in short time period. However because you will maintain the product for long time (years, at least), fewer bugs and good administration system will help you cutting the cost. The longer the product being maintained, the higher the cost is saved.

Documentation!

A good product must have a good manual, and documented. The better the documentation is, the lesser effort needed to support the customer. It may not apply in all case, but at least some are. The more customer using this product, the more documentation is needed.

Idea!

Idea is everything for the lifetime of the product. A stagnant product lack of new features will become obsolete, and lose competition with new products. The terms is coined as product lifecycle. A good idea from the company member has higher chance to be applied.

Conclusion

The business flow of custom IT solution and product developer is different. Their revenue source and cost is also different. How they are managing the development and support is following each business process. A custom IT solution focus more on development time, while product developer focus more into quality. Not every company in each type follow the same rules, There is also custom IT solution who focus on quality, and product developer who focus on development time.

Big or Small Company

Last night I’ve met with my past co-worker at a big company. Before working here at a small company, I’ve worked at a big company for some time beforehand. We talked a lot. Based on their story, the work situation there currently is not far off from last time I was there, or maybe even worse. Same company size, worse workload. It makes me think, how different is it at the big company instead with one in a small company?

Decision maker

In small company, most of strategic decision lies at the hand of the owner. The success factor or future of company lies at the sole hand of the owner.

Meanwhile in big company, The strategic decision are separated by levels. More critical and strategic the decision, the higher the position that make the decision.

Position competency

In big company, a position have clear definition about competencies and required skills. In small company, strategic position usually filled with relations (family or friend), or subjective competency from the owner.

Reward and punishment

In big company, reward and punishment are defined clearly. In small company, it is changing from time to time and only based from oral norms.

Strategic plan duration

Strategic plan in small company usually can be executed faster and clear faster. Usually the strategic plan is planned shorter (days/ weeks/ months) before execution. Strategic plan in big company need more factors to reconsider, has bigger duration and cannot be easily executed. Strategic plan also planned further (years) in big company.

Law

Usually, small company are tend to violate the law more than big company. Especially for tax and employment law. It is basically due to the government can monitor big company more than small company, and big company can easily be exposed when violating law,

Performance

Big company usually has more stable performance. The same performance can be expected with the branches in same area. Small company’s performance are vary and unstable. It is usually based on company owner’s performance, or some skillful’s manpower. When the company lost those skillful manpower, usually the performance go down a lot.

Conclusion

Big company tend to be more rigid and stiff. They don’t change much, but they have clear plans, rewards and rules. In small company, the rules are more subjective based on owner’s view, but they are more agile and flexible.

Hardest : 3rd party system integration

This is the first part of explanation from Hardest : back end enterprise system development article. In this post we will dig down about how hard is it to use 3rd party system into our system.

3rd party system can be either using hardware with drivers, plug ins, or different programming tools such as Microsoft BizTalk and SharePoint. Using 3rd party system in your system sometimes can be easy, or hard. But usually, it is harder than the system development itself.

Different bridging support

This is one of the hardest point in third party system integration. Talking about hardware, usually it comes with built-in driver from the same vendor. However, not every language are supported by the driver. For example, the driver library may not happen to come in python or Lisp language. In worst case, you will need to execute command prompt for bridging with the hardware.

Talking about other programming tools/system, they either provide a supporting language library, or bridging protocol such as tcp/ip, http or command prompt. Different system and different vendor provide different library and bridging method.

Different process

Even in same product type (barcode scanner for example), they can have different syntax, and even different process structure. For example: one use event-driven while the other use threading / polling and the rest use procedural result. The different process structure make it harder to abstract the driver and integrate it with your system. Sometimes it forces your system to change following the process structure.

The same happen when talking about software integration. Most of them have different process and operations. It is hard to abstract them. Moreover, usually they are not supporting transaction processing, making it harder to rollback when error happens.

System error

In some extremely rare side cases, some error can happen in the driver / library or even the component itself. It will makes it harder for the support to identify the error, and the repair will be even harder. In worst case, you need to have the vendor repair the component to even fix the problem, and no workaround can be made.

System Change

Now we get the above problems. Now in some case, the vendor is no longer sustainable and we are forced to change vendor, or the item produced is discontinued and changed with a new one. The can be very costly and time-consuming as well. Change management need to be defined in order to keep business running during the transition, and we don’t have any choice but to do it.

Conclusion

3rd party system integration is harder due to some limitations and lack of control over the component itself. It makes harder to develop, abstract and worse at debugging.

Edit 2015/05/28: 3rd party hardware integration’s scope is too small and is similar with 3rd party system integration. Hence the modification.

Hardest : back-end enterprise system development

What is the hardest thing during developing back-end enterprise system? As a programmer, I have experienced full cycle of building a system in a company from start until being used. Based on my experience, when I try to order them into priorities, this is how I will do it. Please note that this list is different while developing framework/foundation (maybe i’ll list them later):

  1. Handle exception and negative case
  2. Server administration (uptime, backup, re-index, disaster management)
  3. Implementation / publishing / change management
  4. Business requirement gathering
  5. System Documentation
  6. 3rd party system integration
  7. Programming

Of course the priority can be changed based on what system to develop, how good is the company / enterprise with planning the system, etc. And this list can be biased only by my experience alone. But I think the adjustment cannot be shifted very different. If you are a programmer, do you agree with the list? Why is programming / developing the code is the easiest in developing back-end enterprise system? What is my priority based on?

Edit 2015/05/28: 3rd party hardware integration’s scope is too small and is similar with 3rd party system integration. Hence the modification.