Turgay Kıvrak's Weblog

A software myth: Behind schedule, add more people

turgaykivrak — Thu, 21 Apr 2011 22:59:08 +0000

You may have already experienced severaral times that when a project is late or seems to be late, the first solution mostly applied is to add more people. But mostly, it makes the project later. It does not solve the problem but ironicaly creates more problems.

Even with adding more people, sometimes, the project can be delivered as working somehow. However, the team later has to deal with some bugs introduced by these people added. In this case, the problem is just delayed a little bit, and making it more time consuming. Because it always takes more time to fix an issue on an already delivered release.

You may find it hard to believe but Fred Brooks, in 1975, stated it clearly : “adding people to a late software project makes it later” [1], and added that “Nine women can’t make a baby in one month”. (Brooks’ Law)

“If we get behind scehulde, we can add more programmers and catch up.”[2].Unfourtunately, adding people to a late software is a software myth and even worse it is commonly used. Basically, software development is not like building a wall and software developers are not mason. You cannot add more manpower to increase the amount of the work done in a certain time.

But why?

Adding new resource makes others slower. Because they need to help/teach new ones. And you also cannot count them as efficient as the others. They need some time to understand and get used to the project.

Another reason is the increased communication overhead. For N developers, the communication channel number is N *(N-1)/2. As N increases, the number of communication channels increases and the amount of work done decreases.

How to deal with the situation?

Honest promises : Be honest and don’t promise more than what is possible. This is important and applies to whole team including project managers.

Reduce the scope : If possible, meet with the key stakeholders and check if any of functionalities can be dropped, or added in a later phase.

Root cause analyze and fix : Find the root causes of the delay, not blaming anyone, and if possible, fix it. Sometimes it is the motivation of the team, and in this case, the factors which decrease the motivation should be carefully indetified and solution to increase the motivation should be based on it.

Realistic plan: Revise the project plan with delay and/or create a realistic project plan with more realistic revised estimations.

When is it useful?

Adding manpower can be useful if the current team has trouble with some difficulties and they cannot easily overcome and the new members are experts for that kind of problems.

[1] The Mythical Man-Month: Essays on Software Engineering, Fred Brooks

[2] Software Engineering – A practitioner’s Approach, Roger S. Pressman

Filed under: Software Engineering

A Collection of Lessons Learned From My Last Decade on Software Development.

turgaykivrak — Tue, 28 Dec 2010 23:29:00 +0000

No language fanatism : All languages are like tools in your toolbox. Just use the most suitable one, which is not necessarily the most popular one.
Measure progress and make it visible, even when you are doing it yourself. Use board and charts.
Code base is like your house. Always keep clean, otherwise after a while, you can find yourself in a mess. Refactor.
Always be very humble. There is always someone better than yourself. The greatness is hidden in being small.
Continuous learning. There is no stop in learning, learn until death. Read beatiful codes, designs, books, blogs, etc. Improve your skills.
No frozen well defined requirements. Change is part of life like time, it is in nature of things. So is in development, then always be prepared for it. It is not a thing that bites you, it is something to tackle.
Help others. Always be open to help others, especially juniors. This is kind of being thankful of having knowledge. The best way to learn is to teach others.
Unit test. The more unit test, the less debug. Skipping unit test to gain time is an illusion.
Keep being on the mid-way. Never overuse anything. Never overuse design patterns, never overrefactor, never overdesign, etc.
Developers always underestimate. Most of “2-min work”s are not 2-min. Be aware of that and always add a little slack on estimations.
There is no end in development. Stop developing at some point.
Simplicity, simplicity, simplicity. Simplicity, simplicity, simplicity.
No gossips : Never gossip. Never listen gossips. Never let them decrease your energy. Be smart and aware and observe environment to know what is going on, but no gossips. If you have a problem, talk to related people.
Use version control.
YAGNI :“Always implement things when you actually need them, never when you just foresee that you need them.” (Ron Jeffries). Developers always tend to develop things more generic, for possible future use purpose. However, most of this possible future never happens. So, even if we are very sure that we will need a feature in future, we should not implement it now, we should implement it when the expected future comes.
Stabilize pursit of perfection with pragmatism.
Continuous integration
Communication is important. One of the most important and difficult thing is software development is communication. Clear communication in the team and clear communication with clients. And be very specific to unprofessional people.
Focus on delivering working software and deliver frequently.
Remember the big picture.

Filed under: Software Engineering

Arrogance, humility and software development

turgaykivrak — Sat, 23 Jan 2010 21:33:38 +0000

One’s true greatness is inversly proportional to behaving as if one were great, just as one’s true smallness is inversly proportioanl to behaving as if one were small. (Anonymous)

The more I learn, the more I realize I don’t know. (Albert Einstein)

You should have heard about how arrogant developers are terrible in communication with team members and client or you should have met an arrogant developer who never listens anyone else, thinks he knows everything and who is also very rude.

Once upon a time, you might have had at arrogant aggressive collages, who cover their frustrations with aggression, finding yourself in feeling of “never be part of anything which they are in”.

What is arrogance?

Arrogance is an offensive display of superiority and self-importance. It destroys professionalism by reducing the individual’s ability to think for himself or herself, making empathy for others difficult and removing the checks and balances of self-doubt.[1]

Arrogance is the reason for many failures. It could kill any company in any stage of its life. It could kill any work in any stage of its life. If you analyze the failures of the giants, you will see that most of their failures come from their arrogance.[2]

So why are people are arrogant? It is a mask hiding various types of states: It is a way to fill the inner emptiness with a big ego, actually, which makes them a slave of their own ego. Also, it is a way to cover up insecurity and frustration.

Personally, I don’t know anyone who likes arrogant people. They are not being more appreciated, not more admired, on the contrary, peoples dislike them.

I believe that it is one of the worst thing in business to have arrogants. They cause a tremendous amout of discord in the workplace. They ignore others and separate themselves from others, and pull down the energy level of the people.

Lets consider developers’ arrogance, generally they cannot learn from others, they reject it. They even don’t listen others. They are very rude in discussions, which they make it go nowhere. So, in this situation, who is the looser? In the team, they hurt the team spirit. They are a kind of obstacle slowing down the team to reach the goal. To put it short, their damage is to both themselves and the team.

How to deal with arrogant

The belief of that you have to be arrogant to survive in an arrogant world is nothing but adding fuel to the fire. Considering it is more likely related with inner problems of the arrogant, responding with arrogance only makes you another arrogant, nothing more. It doesn’t help solving the problem with only exception that the arrogant may feel seeing himself in the mirror. But it is very hard to see it in negative response. Being cool and sedate or being confident in silence help more.

If you feel arrogant

When you feel arrogant, here is the motto : Treat others as you would wish to be treated yourself. Think you’re just human, ordinary mortal human. Be sure , somewhere, there is a better professional than you, and also he/she is smarter and more genios than you.

Breaking of arrogance starts with seeing it, and knowing it. The people around you and feeling of something is wrong with you somewhere inside you may be hints. Accepting and seeing the truth of that we are at the same level of importance as others is a cure for arrogance.

The feeling you have when you see the greatness of your work and your thought should not lead to arrogance, you should be thankful to have that gift, keeping in mind that it is given to you to use in benefit of humans.

If you look at life, you can also easily see every extraordinary thing given to the human is supposed to be used in benefit of others and if he uses it for himself, like arrogance, he pays a lot for it. So, even if you are gifted, there is no excuse for being arrogant.

Arrogants are knocked out sooner or later, without any exception. One day, they find themselves brought down to the floor. This is how it works. You can easily find many instances of this situtaiton in the history. A lot of giants vanished because of thier unwarranted arrogance.

Cofidence vs Arrogance

Confidence and arrogance are different. Arroagance goes beyond healty confidence. Confidence is being aware that you know something, whereas arrogance is being overly concerned with aware that you know something.

Humility

Humility, or being humble, is the defining characteristic of an unpretentious and modest person, someone who does not think that he or she is better or more important than others. Because the concept of humility addresses intrinsic self-worth, it is emphasized in the realm of religious practice and ethics where the notion is often made more precise and extensive.[3]

Dignity of the knowledge and wisdom requires humility, which is one of the greater virtues one of the most appreciated personal qualities.Its absence is a direct obstacle to comunication; and can generate enemies, so it’s a necessary social behavior and part of being professional.

Humility comes with being aware of your strenghts, weaknesses and abilities. This also gives you the ability to approach situations in a superior way. Extreme humility [4] is a nice example for it.

Humility is more useful in problem solving; you don’t trust your self blindly and fail and blame other people or other things for failure. To put in another way, you will find that you are much more open to opportunities to learn and improve the project you are working on.

And software development

Humble people are a lot more pleasant and easy to work with. They don’t make their superiority an issue, they don’t always know better, they listen and respect and value others’ ideas.

Arragont developers! You’re killing what you’ve done and your team’s work .You are not being more appriciated, not more admired, on the contrary, you are loosing them. Your ego keep you from being great developer. The more humble you are, the faster you’ll improve. So, why arogance?

Developers! Know your strenghts, your weeknesses, know what you know and what you don’t. Be open to communication, listen others, respect people. Be confident about yourself, but never ever be arrogant. Knowing yourself, your capabilities and inabilities leads you to a way for improving your skills.

Everybody can make mistakes, everybody can write code in poor quality, but the virtue is to admit it and learn from them.

Managers! Even you may be in a dazzling position, but it does not require to be arrogant. First of all, never ever be arrogant. And do not hire arrogant people. If you have any between your employees, give a bit time to them for recovering themselves from arrogance and also help them in doing that, if they still persists, get rid of them. Value confidence. Never forget your team is very important.

References

Professionalism Initiative http://www.kumc.edu/som/professionalism.html
Success, Arrogance, Rise and Fall http://eclipse.sys-con.com/node/43873
Humility http://en.wikipedia.org/wiki/Humility
Extreme Humility http://c2.com/cgi/wiki/wiki?ExtremeHumility

Posted in Other, Software Engineering

Verify details of argument passed to the mocked object

turgaykivrak — Fri, 22 Jan 2010 22:21:02 +0000

Mockito,my favoritte mock library, introduced ArgumentCaptor with 1.8. ArgumentCaptor allows you to capture and store arguments passed the mocked methods.
The captured arguments are available with the methods like getValue and getValues.
So, the arguments can be easily verified by using standart JUnit assertions.

ArgumentCaptor argument = ArgumentCaptor.forClass(Person.class); verify(mock).doSomething(argument.capture()); assertEquals("John", argument.getValue().getName())

Posted in Java, Unit Test

Value Objects

turgaykivrak — Sat, 26 Dec 2009 23:10:12 +0000

The value objects are simple but very useful objects. Value object, one of the powerful concept from DDD, is an object that describes a characteristic of a thing.

According Eric Evans,

“An object that represents a descriptive aspect of the domain with no conceptual identity is called a value object. Value objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.” [Evans 2003]

Here a few characteristics of value object:

The key defining characteristic of a value object is that it has no identity. In other words, the intention of a value object is to represent a concept by it’s attributes only.
They should probably be immutable, once created they cannot be changed or altered.
They are not DTOs, not Java beans and not objects with public fields, they encapsulate data with some behavior. DTOs are bunch of data, which are not necessarily coherent, VOs contains high-chorent data with behavior. The purpose of DTOs is data transfer but the purpose of the VOs is domain representation.
They are mostly very simple objects.
They “swallow computational complexity”.
More extensible
More testable

Some examples of value objects are money, addresss, phone number, product code, email address, etc..

A Concise solution for hashCode() and equals() implementations

turgaykivrak — Tue, 23 Jun 2009 21:13:55 +0000

Currently, I was working on improving code quality. Some of the violations were due to the code generated by eclipse for hashCode() and equals() methods in the domain model classes. I was thinking on writing a builder classes for these methods, later on I just came across the Apache Commons Lang builder classes. It was even better than I imagined:)

Actually, the Apache Commons org.apache.commons.lang.builder package contains builder classes to help implement methods like equals() , hashCode() , compareTo(), and toString().. They are implemented to follow rules from in Effective Java , by Joshua Bloch

Considering clarity, readability and maintainability of the code, they are very concise and consistent solution.

The EqualsBuilder
Here is the sample usage of EqualsBuilder from API docs.
public boolean equals(Object obj) { if (this == obj) { return true; } if (obj == null) { return false; } if (!(obj instanceof MyClass)) { return false; } MyClass other= (MyClass) obj; return new EqualsBuilder() .appendSuper(super.equals(obj)) .append(field1, other.field1) .append(field2, other.field2) .append(field3, other.field3) .isEquals(); }

It is good to be carefull with isEquals() method, it is a common mistake to use equals() of the EqualsBuilder instead of isEquals().

The HashCodeBuilder
Here is the sample usage of HashCodeBuilder:
public int hashCode() { return new HashCodeBuilder(). append(field1). append(field2). append(field3). toHashCode(); }

It is good to be careful again with toHashCode() method, it is a common mistake to use hashCode() of the HashCodeBuilder instead of toHashCode().

Alternatively, you can use the reflection-based static methods:
public boolean equals(Object o) { return EqualsBuilder.reflectionEquals(this, o); } public int hashCode() { return HashCodeBuilder.reflectionHashCode(this); }
However, I think reflection implementations are not good for a real project: They are potentially much slower and it is very important for domain model, the fields icluded in these methods should be carefully and intentionally selected considering the implication on the model.

Posted in Design, Java

Optimistic Locking and Versioning in Hibernate

turgaykivrak — Sat, 16 May 2009 21:12:23 +0000

What is optimistic locking?

Optimistic locking is a method used to prevent simultaneously access problem on the same entity for change, which does not lock on the database level, in order to maintain the correct data.

For example, if two user wants to update same entity in different transactions, when first one saves and then second one saves without getting updates from the first user’s change, who will be the winner?

Most of the web applications, like ours, has such cases: Two users retrieve and modify a data on the page, then first user saves the data a transcation and then second user modifies and saves the data in an another transacion. Here are 3 alternatives:
1. Last commit wins : Both updates are performed, the second user overwrites without seeing the first user changes and without any error message
2. First commit wins : (Optimistic Locking) The update is performed, but second user gets error message, requiring restart of the processes on the first users changes.

3. Merge conflicting update : The second user are prompted to merge changes.

Automatic Versioning

Hibernate provides automatic versioning for options 2 and 3, using a version field managed by hibernate.

Versioning with integer version
public class MyClass { ... private int version; ... }

...

Versioning with timestamp
public class MyClass { ... private int lastModifyDataTime; ... }

...

Automatic versioning is handled by hibernate, you don’t need to update versions/timestamps.
Considering the example mentioned above, when second user saves, hibernate finds this user is working on the stale data and throws StaleObjectException.

You can catch this exception, and rethrow your own exception. By the way, if you’re using Hibernate with Spring, this exeception is wrapped with HibernateOptimisticLockingFailureException.

One more point, you should be aware of that hibernate ignores the versioning when getting object and updating fields and then version are in the same session.

Posted in Design, Hibernate, Java, Spring

User access to another schema in Oracle: Alternative to public synonyms

turgaykivrak — Wed, 25 Mar 2009 23:29:36 +0000

Consider that there are 2 users in your database having their own schemas, but second user having less permission is required to work on the first schema. Possible solutions :

1 . To create public/private synonyms

2. Use schema name in the queries.

3. Modify user session to point the first schema. Create a trigger on login.

CREATE OR REPLACE TRIGGER &app_user..APP_USER_LOGON AFTER LOGON ON &app_user..SCHEMA DECLARE

BEGIN

            EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = '|| UPPER('&owner_user');

   EXCEPTION

     WHEN OTHERS THEN raise_application_error(-20001, 'Error: ' || SQLERRM );

END ;

Posted in Database

Spring Security: Authenticate user on LDAP without manager/admin user

turgaykivrak — Wed, 25 Mar 2009 23:26:45 +0000

In my previou post on spring security with LDAP, I had used a manager/admin user to authenticate a user.

You can use the following code to authenticate the user directly, without manager/admin user:



  
    
    
      
        CN={0},ou=Users,dc=example,dc=com

Posted in Java, Spring

Spring Security : Use Ldap for authentication, and database for authorities

turgaykivrak — Thu, 12 Mar 2009 22:15:35 +0000

If you need to use Ldap for authentication and database /repository for authorization with spring security, here is a sample:

LDAP authenticator configuration




  
  
    
      
      
        uid={0},ou=Users

Authorities populator:

public class MyAuthoritiesPopulator implements LdapAuthoritiesPopulator {

	private MyUserService userService;

    public MyAuthoritiesPopulator(MyUserService userService){
       this.userService = userService;
    }

	@Override
	public GrantedAuthority[] getGrantedAuthorities(DirContextOperations userData, String username) {
		Set userPerms = new HashSet();

        //get users permissions from service
		Set permissions = userService.getPermissions(username);

		for (MyPermission perm : permissions) {
				userPerms.add(new GrantedAuthorityImpl(perm.getName()));
		}
		return userPerms.toArray(new GrantedAuthority[userPerms.size()] );
	}
}

Posted in 1, Java, Spring