Tuesday, 6 September 2011

What’s the worst: Bad project management or project with bad code???

 

In my point of view, both are quite bad, though as we don’t live in a perfect world, usually we have to pick one, and make it as good as we can.

Nowadays it’s quite common imposed leaders with quite few knowledge in IT, or when have any knowledge in IT its quite out dated.

As Architect/Developer and had been owner of one Consultant company for 10years, from my experience I can say that have a good view from both, and everything will depend on what side you are. For example, if you are in charge of one project, and that has a short time to delivery, you will not give too much importance to code quality, what you want and need it’s delivery it in time, because after that you will be working without monetary incoming, apart that it will make you look at front of others less competent now if you are a developer in this project (and not a very experienced , just average one), such probably your code will not be so good, due the pressure and the short time and logic issues with the code, like poor cohesion and few component reutilization, many strings duplicating values inside the code, magic numbers, bad use of collections if a Java developer, tough the code hopefully will be working well and once you delivery the code will feel relieved.

In my view the code shows too much of you are, clean code and very structured are the best to understand and maintain, though sometimes due that rush, make the right choice it’s hard to implementing, because means re-write several classes, deleting others, updating references and so on… if you are in one pure java project it’s reasonable easy to do, though if not, will be very time consuming.

I think that the best option is keep with the standard from the system, of course if it’s too bad, you will change a few things to make it slightly better, but changing many things, will make things worst, may be not for you, because you remember what you have done, though for any other that will start ‘reading” the code, will be worst.

If you don’t agree with me, it’s just remember when you get that system that had several duplicate APIs doing the same thing, have you stoped to think the why of that? It’s because someone came and thought something like that… this is bad, I can make it better, and then create a new component, but as the old one it’s been used for several other system that such probably work with exported jars that you simply can’t change. Now look of what you have done… made your life easier and of everybody else harder, because when someone start looking in the system will look for that old component because most of the code will point to that, and will take sometime to realize that there is a new component, that it’s only your code that it’s using it.

If you have to create something new, or have time and control over all project, then it’s an excellent idea make things right from start.

Good code today doesn’t mean that it will keep being good tomorrow, because people change, versions change and even the way to implement it change over the time, though if you keep in mind always that performance it’s the holy grail, than such probably your code will keep good for longer than just a nice and easy to read code.

Now changing the direction a little bit…

Bad project management it’s the worst thing ever in IT, due that even a bad coder can make a well structured project work, though a bad designed project, will suffer with issues forever, doesn’t matter if there is a awesome team behind, if specs where bad, everything else will be bad or useless, also doesn’t matter if the code it’s awesome or really bad, the project has failed, the boat sunk and you were there together.

One other big problem today with IT, it’s that people that doesn’t have a good logic are writing code, or even worst, people that simply doesn’t like of IT, they are in the profession just to make money because it has many jobs available, those ones are that one that make the bad name of IT with the management sector.

Other issue it’s with those “Architects” that just know one language and in most of time one framework. If you are one of them please stop and rethink what you are doing… such probably it’s throwing your career through the window, because your chances to succeed are quite smaller if you do your homework, other else it’s none .

Agile projects… It’s GOOD, very good, though will in fact work well if you are or have a experienced team, if most of team mates are Jr’s forget it, because it will not work also if you have worked for whole career in waterfall methodology your chances in succeed in an agile project are tiny, in 21 years in the area never saw one that had tried achieve success, this take time, and for you get there it’s good first pass through some agile team that it’s doing it for a while, to see and try acquire the most of knowledge from it to avoid pitfalls later.

Defining success : It’s when you make things work well in time, in other words delivery the project working as expected in time, doesn’t exist half success, what exists it’s in the best of cases, self improvement, but not success.

To finalize here being short, due that this topic we can write a book and wouldn’t be enough, it’s better have a better project management, specs, requirements, a closed and well defined domain than just good code, if you have both it’s perfect.

Just try make things right, not thinking just in yourself, because usually what’s good for the developer or developer team isn’t so good in production, though it’s talk to an other post.

Monday, 16 May 2011

Tips to identify or be a Good Leader in IT

 

When I say Good Leader means a real good one, not an average one, because this rare species of talented people it’s quite hard to find out.

Let’s see a few points that in my experience worth to note here, of course that there is quite more, I can write a book talking and giving examples about it and will still have a lot more to talk.

A good leader:

Don’t use the first person I when speaking to/with the team or with superiors, use always WE, because s(he) like or not, it’s not only s(he) achievement, it’s a team achievement, means that everybody worked together for one goal, because s(he) can’t succeed without the team, the only reason of s(he) be a leader it’s because there is one team to lead. Right!

When the projects succeed is our achievement other else it’s our fail and not “I did it work” or “My team has failed”, usually is “We did it” or “We do have failed”. The biggest problem with this approach is that when project fail s(he) superiors will point the finger to the leader, that in other words means to the team, though it’s rare people that do that, due the lost job fear, that take to an other conclusion, if s(he) has afraid to lost the job means that s(he) doesn’t have confidence or know that s(he) isn’t good as was sell, and to find out other job is quite hard.

Make the team motivated, making them work having the sensation that they are part of something important, have the knowledge to extract the best of each member, knowing their personalities help to avoid pitfalls and interpersonal issues and helps when s(he) need push them harder, because very often the respond as expected.

S(he) is pro-active, have the “Can do” attitude, it’s a positive person, with feet on ground.

Leader has to listen a lot, has to behave as a shield/ filter for the team, avoiding let them have issues with problems that doesn’t concern to the team and the work.

When know something that is useful for the team, share it.

When doesn’t know something, say that doesn’t know, though will do some research and then give a feedback.

It’s not a centre person, he delegate responsibilities, has that attitude “help me help you” and when needed know demand the result.

S(he) like to hear ideas from the team, mixing with their own if necessary to have a better solution.

Doesn’t abuse of technical language, usually when talks it’s look like a conversation.

To be a good leader it’s fundamental that s(he) have technical knowledge to talk with equal conditions with the team, and not using that “high level language” , that just make the team have that image of s(he) that doesn’t know what it’s s(he) is talking about.

Has to know when and with who use the “high level language”.

Good leader like to work with up to dated people, those ones that enjoy challenges and are always looking for learn something new, s(he) feel comfortable among them and not scared.

Usually when the team and s(he) achieve some good results, s(he) name in is know very rare occasions. Usually we just know the achievement made and you can see that the company is going well than before with them

S(he) enjoy when things are going well (who not?), though when things are tough s(he) also enjoy because it’s like a test and s(he) has to improve to overcome the problem and this self improvement is s(he) goal too.

When they fail, they don’t go on a witch hunt crusade, s(he) seat calm take a breath and start analysing where and why it went wrong for that pitfall/problem never happen again.

They look you in the eyes when talking, and you have that feeling the s(he) really know about the conversation topic, and in fact the know it.

Has a lot experience in several situations and responded well in most of them.

S(he) doesn’t care too much for himself/herself they give value to the achievement.

As this is just a blog, those are few characteristics that a good leader must have in my opinion that is based in my years of experience. Though there is a lot more, here I just talked about personality to be a leader, that in my view is one the most important and the most hard to find out.

Please if you want to include something or disagree feel free to comment.

Cheers