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.


Wednesday, 15 December 2010

Performance : A few tips that worth to implement.

These tips will help you have faster applications, and most of that are to be implemented with Java.
1 - Client (UI) should (must) be thin client :
Don’t create client that do too many things, specially DAO to load reference tables each time that you need load the page. Thin client should do basic validation just to have data integrity, like date formats and range, numbers ranges, if that field can accept null or not, business rules as the name say should be performed in business. If you have one screen with multiple tabs, try create it as separate, JSP/XHTML pages, for page to each one tab, with independent validations happening just before you jump to the next tab, and go passing the object populated till you get into the submit page. Doing this, you will load few objects each time in memory and smaller pages too. Try keep at minimum those submits, most of instance variables that aren’t being used should be set to null, with this the GC will collect them faster.  There are a lot to talk about thin client, actually exist books talking about it, though if you follow this, will help you a lot with performance. UI should never make call to DAO, everything should come ready from Business layer, if you need keep those drop down lists updated all the time, use cache and dependency injection (old IOC) in business layer to keep those caches updated.

2 – JPA/Hibernate mappings, should be consistent, with database design
I know that today we have ORM, though a lot of people see it as a recipe to ignore all good practices about relationship. What I can tell here is respect the  entity-relationship, and use lazy, or if you do need just one data, and this data is strictly necessary, perform one single and simple read using native query in that table. The database design, I mean internally is made to work using entity-relationship, and if you create it in creation time, you should use it to have the best performance with it. I’m not saying that ORM will be bad to performance, but it bad when everybody that has to implement one new feature, create one new ORM relationship that doesn’t follow what the database was designed for, and with it after some time start being really hard fix it, due a lot of mapping and code has to be changed. Try keep it simple and functional without implement to many mapping-relationship with no need. If you need for many things and you have good reasons to use it further so implement it, now if it’s just for one or two things, don’t do it.

3 - JSF 1.2 and Facelets are good
Actually are awesome, they are so good that JSF 2, is 1.2 with improvements and Facelets,  the biggest problem is the way those systems were designed, a lot of people doesn’t really know JSF and Facelets properly and they instead read more about it and look for good implementations, they use the easiest one got from internet, or try use it as the old Struts work, that’s as action based framework, and in the end they have one very hard to maintain system, bloated with more layers than needed and with bad performance.

4 – Objects in memory, control them, use just the necessary
There a lot system that load a lot objects in memory without use, they keep in there up to they are needed, or worst the load several times the same object in memory with different instance names. Think this way, it’s better one big object in memory than several smaller ones using the same amount of memory, just because you consume less resources from you processor, doing the GC work less checking all the time what is needed to be collected. One rule of thumb is if you will need update just a few fields from one object, don’t load another in memory and then in the end merge them. Use local objects, that will be destroyed as soon the task is completed, try use primitive types in memory and then “persist” then into the object. Think that if your system is part of one enterprise one, not all resources will be available all the time like in your personal environment. There your system such probably will work together with several others systems all them consuming resources from server or servers, all them using the same memory, IO and everything else. Try use static to all those methods that make part of validations, this can cause some sort of bottleneck though will avoid memory leaks, and several instances that doesn’t being used in memory. Try keep the design clean, something like having one object for the screen, that will be converted after submit to BO and that the persistence layer in the end will split it and them persist into database.

5 – Avoid to use Strings
Instead use StringBuffer or StringBuilder, and preferably instantiate quite few and reusing it always as needed. Try use static ones, and “don’t use this” in comparations, print’s, since that it will never change. Use java standards to create names.

6 – Database connection, is the most expense resource that you will have
Even today I see a lot of system using DAO the wrong way, and most of them never have heard about use caches. The just let the AS take care of everything (as if should work). One good idea make the DAO layer one little bigger than just only CRUD operations. Try read about JPO (Java Persistence Objects), roughly speaking DAO should give to Business layer the BO ready and not in parts, entities alone for that Business has to convert it and discover soon after that will need again one other read (or several others) to complete the request. Loading or doing all necessary reads and populating once the BO object it’s good also because will open the connection just once, do everything needed and then close, maybe you don’t know about it though if you are using one data source your AS is doing it for you.

7 – Use of Web Services
They make a lot of sense if you have several technologies that should consume your system, if using just Java, try use serialized objects that is quite faster. Worth take a look into the granularity of those WS’s to check if some parts of it can be used for others services. But is essential that you migrate to WS those “services” that will doesn’t change very often and in rare cases create WS (WSDL) that will carry on huge objects as request and response.

8 – Have the most close environment as production in one machine
This’s really important thing, that will can test several settings to memory, data sources, and to check as your system is consuming the machine resources, and it’s good too to perform stress tests. Just making one good tunning in your AS will grant you at least 40% improvement in performance.Tweaking your AS will make a big difference.

9 – Don’t leave instance variables that aren’t being used to be collected to GC.
If you set as null every time that you will not use it anymore, will save a lot of resources from your machine.

The basic thing that you must have in mind is that in production very often all machine resources are shared among other systems, OS, AS, and that you can’t just go consuming it without think in consequences, and that there is not like in your machine, that when need perform one IO or use more memory is just do it, most of the cases the database is not in the same machine that your system, think always in economy of machine resources. That will make your system perform with performance.
There are a lot more rules that should be followed to have a good performance, though those are the main ones.
If you that are reading it have anything  to add please feel free to put comments.

Sunday, 3 October 2010

Persistence Domain Objects and Some Good Practices

In this post I’ll talk about Business layer, PDO and a few tips that will help you to have less complexity into Business layer and have one Persistence layer that will delivery data's ready to use for the Business layer.

Today most of Business Domain follow roughly this pattern:


Where the Persistence layer is just for DAO, that is nothing wrong with it, but it doesn’t delivery data’s ready to use for the business, and because of this, it gives you one swelled Business layer, where does more than just business, especially with data's that come from Client side and Persistence layer, that’s needed convert then from entities to BO’s and then to TO’s  (or the old DTO’s). This’ telling me that the Business layer is doing more than just business is doing something else than business, where it should only take care of how data’s should be manipulated  and returning the result. Business layer shouldn't know about Persistence, should just make one call like getCustomerBO(); and work with it, not like is today, where’s needed populate all entity's then ‘filter’ the data that is needed to create those BO’s, then work with data’s and then populate those TO’s to return the result to the Client side.

One good idea that’s for sure will make your Business layer more thin, easy to maintain and performing just business tasks. Is model your application with real objects and don’t care about the Persistence layer at beginning. Real Objects means cohesive classes with encapsulated state, related behaviour and inheritance. Putting just business logic into the domain business objects, using inheritance where appropriate.

To resolve this we have an alternative that is move the convertor and BO’s to the persistence layer, and then your Business Domain will looks like this chart :


Following this your persistence layer will delivery BO’s ready to use for the Business layer.

In the next post I’ll go post here one very small example of this implementation.

Sunday, 26 September 2010

NoSQL – One Simple CRUD Example

Here I’d will explain how simple, with the right .jars, is work with NoSQL, in my example will be used the CouchDB, that is pretty simple and easy to install and make it run. Basically just unzip it and run the .bat file.  For any other explanations about NoSQL databases please go to this llink, or to this other one.

.jar’s that you will might need

Json lib
httpClient and httpCore

Here we’ll create one very simple example with simple table and no relationships.

Field name


We don’t need to worry with the field types due that the document, is a JSON object so, just strings and you must perform the conversions later on. Here one simple JSON document as example:


CouchDB reserve those fields starting with _ (underscore) to be used to itself, e. g. : _id , and the _id itself is a primary key.

As I’m using the CouchDB as localhost and the default port to access it is 5984, and to do any sort of access into CouchDB you must have one session created, in other words session is mandatory.

   1:  package au.com.nosql.main;
   3:  import com.fourspaces.couchdb.Database;
   4:  import com.fourspaces.couchdb.Document;
   5:  import com.fourspaces.couchdb.Session;
   6:  import com.fourspaces.couchdb.ViewResults;
   7:  import java.util.List;
   9:  public class NoSQLMain {
  11:     public static void main(String[] args) {
  12:        boolean exist = false;
  13:        Database db = null;
  15:        // Creating the session
  16:        Session mySession = new Session("localhost", 5984);
  17:        String dbname = "employeeTest";
  21:        // Check if the database already exist, if not create
  22:        // Including one document into my new database
  23:        List<String> dbsNames = mySession.getDatabaseNames();
  24:        for (String dbName : dbsNames) {
  25:           if (dbName.trim().equalsIgnoreCase(dbname)) {
  26:              System.out.println("Already exist the database with name" + dbname);
  27:              exist = true;
  28:              break;
  29:           }
  30:        }
  32:        if (!exist) {
  33:           mySession.createDatabase(dbname);
  34:        }
  36:        db = mySession.getDatabase(dbname);
  38:        // create one document and save it
  39:        Document doc = new Document();
  40:        doc.setId("1");
  41:        doc.put("EMPLOYEE_ID", "0001");
  42:        doc.put("FIRST_NAME", "MyFirstName");
  43:        doc.put("FAMILY_NAME", "MyFamilyName");
  44:        doc.put("GROUP", "JAVA");
  45:        doc.put("FUNCTION", "Developer");
  47:        db.saveDocument(doc);
  48:        doc = null;
  50:        // Retrive that list of DBs
  51:        List<String> listofdb = mySession.getDatabaseNames();
  52:        System.out.println("Number Total Of Databases: " + listofdb.size());
  54:        // Displaying the current number of documents
  55:        int count = db.getDocumentCount();
  56:        System.out.println("Total Documents: " + count);
  58:        // Retriving a single document
  59:        Document getOne = db.getDocument("1");
  60:        System.out.println("Document returned from database : " + getOne.toString());
  61:        getOne = null;
  63:        // Delete the document from Database
  64:        getOne = db.getDocument("1");
  65:        db.deleteDocument(getOne);
  66:        count = db.getDocumentCount();
  67:        System.out.println("Total Documents after delete : " + count);
  68:        getOne = null;
  71:        // cleaning all docs if exist more than one
  72:        ViewResults viewResults = db.getAllDocuments();
  73:        List<Document> docs = viewResults.getResults();
  74:        for(Document doc1 : docs) {
  75:           System.out.println("Document to be deleted : " + doc1.toString());
  76:           db.deleteDocument(doc1);
  77:        }
  80:        // Delete the database
  81:        mySession.deleteDatabase(dbname);
  82:        listofdb = mySession.getDatabaseNames();
  83:        System.out.println("Number Total Of Databases after delete that created one : " + listofdb.size());
  85:     }
  86:  }


There is one other way to persist one NoSQL DB is using HTTP:

HttpClient httpclient = new DefaultHttpClient();
HttpGet get = new HttpGet("http://localhost:5984/employeeTest/_all_docs?startkey=%221%22&limit=1");
HttpResponse response = httpclient.execute(get);


Or :

HttpGet get = new HttpGet(http://localhost:5984/employeeTest/_all_docs?startkey=%223%22&endkey=%226%22)

Where %22 is used for single cote ( ‘ ).

One last thing, have in mind that CouchDB is not a relational database, so it will just allow querying data based on "key" only, so we cannot retrieve data based on field values from such databases.

This is just a simple example using CouchDB and with one very simple table structure, though for more complex things, as the DB is not relational you will need search using keys and then populate it to create what you might need.

Thursday, 16 September 2010

XStream – One example

Here I'll talk about my last experience using the small, however very powerful marshalling/unmarshalling XML framework, the Xstream, you can check it out into http://xstream.codehaus.org/ .
First of all, this framework has a very small API, especially for persistence and it's very powerful and fast to export your objects for one XML file, though to read it you need use JAXP, JAXB, IO or ant other library that read XML code, even the NIO from Java 6 will work.
You can download the binaries from here.
After unzip the file in your choose destination, you will have into the folder this tree, here in my case I'm using the version 1.3.1 :

  doc API's and tutorials
  libs .jars / libs
  LICENSE.txt Text files
  README.txt Text files

You will require xstream-[version].jar and xpp3-[version].jar in the classpath. XPP3 is a very fast XML pull-parser implementation. If you do not want to include this dependency, you can use a standard JAXP DOM parser instead.

And here our bind classes, pojos :

ShipTo.java :

public class ShipTo {
    private String name;
    private String address;
    private String city;
    private String country;
    public String getName() {
        return name;
    public void setName(String name) {
        this.name = name;
    public String getAddress() {
        return address;
    public void setAddress(String address) {
        this.address = address;
    public String getCity() {
        return city;
    public void setCity(String city) {
        this.city = city;
    public String getCountry() {
        return country;
    public void setCountry(String country) {
        this.country = country;


Item.java :

public class Item {
    private String title;
    private String note;
    private String quantity;
    private String price;
    public String getTitle() {
        return title;
    public void setTitle(String title) {
        this.title = title;
    public String getNote() {
        return note;
    public void setNote(String note) {
        this.note = note;
    public String getQuantity() {
        return quantity;
    public void setQuantity(String quantity) {
        this.quantity = quantity;
    public String getPrice() {
        return price;
    public void setPrice(String price) {
        this.price = price;


ShipOrder.java :

public class ShipOrder {
    private String orderid;
    private String orderperson;
    private ShipTo shipto;
    private List<Item> item;
    public String getOrderid() {
        return orderid;
    public void setOrderid(String orderid) {
        this.orderid = orderid;
    public String getOrderperson() {
        return orderperson;
    public void setOrderperson(String orderperson) {
        this.orderperson = orderperson;
    public ShipTo getShipto() {
        return shipto;
    public void setShipto(ShipTo shipto) {
        this.shipto = shipto;
    public List<Item> getItem() {
        return item;
    public void setItem(List<Item> item) {
        this.item = item;


Now our class that will serialize to one String as XML and then de-serialize to Objects.

   1:  /*
   2:   * To change this template, choose Tools | Templates
   3:   * and open the template in the editor.
   4:   */
   5:  package xstreamtest;
   7:  import com.thoughtworks.xstream.XStream;
   8:  import java.util.ArrayList;
   9:  import java.util.List;
  11:  /**
  12:   *
  13:   * @author Klaus
  14:   */
  15:  public class Main {
  17:     /**
  18:      * @param args the command line arguments
  19:      */
  20:     public static void main(String[] args) {
  21:        // Getting the Xstream
  22:        XStream xstream = Main.getStream();
  24:        // Serializing the object to XML
  25:        ShipTo shipTo = Main.getShipTo();
  26:        List<Item> listOfItems = Main.getItems();
  27:        ShipOrder shipOrder = Main.getShipOrder(shipTo, listOfItems);
  29:        // Serializing to the XML into one String, can create file if you want it.
  30:        String shipOrderXml = xstream.toXML(shipOrder);
  32:        // Display the XML created
  33:        System.out.println("The XML :");
  34:        System.out.println(shipOrderXml);
  36:        // Populating the obj again
  37:        ShipOrder shipOrder1 = (ShipOrder) xstream.fromXML(shipOrderXml);
  38:        ShipTo shipTo1 = shipOrder1.getShipto();
  39:        List<Item> listOfItems1 = shipOrder1.getItem();
  41:        System.out.println("-------------------------------");
  42:        System.out.println("- Desirializing to the object -");
  43:        System.out.println("-------------------------------");
  44:        System.out.println("Order Id     : " + shipOrder1.getOrderid());
  45:        System.out.println("Order Person : " + shipOrder1.getOrderperson());
  46:        System.out.println("Ship To      : " + shipOrder1.getShipto().getName());
  47:        System.out.println("Items : ");
  48:        for (Item item : listOfItems1) {
  49:           System.out.println("Title : " + item.getTitle());
  50:           System.out.println("Qtde. : " + item.getQuantity());
  51:           System.out.println("Price : " + item.getPrice());
  52:           System.out.println("Note  : " + item.getNote());
  53:           System.out.println("-----------------------------------------");
  54:        }
  55:     }
  57:     public static XStream getStream() {
  58:        XStream xstream = new XStream();
  59:        xstream.alias("shipTo", ShipTo.class);
  60:        xstream.alias("item", Item.class);
  61:        xstream.alias("shipOrder", ShipOrder.class);
  62:        return xstream;
  63:     }
  65:     public static List<Item> getItems() {
  66:        List<Item> items = new ArrayList<Item>();
  67:        Item item = new Item();
  68:        item.setTitle("Item 01");
  69:        item.setPrice("10.00");
  70:        item.setQuantity("5");
  71:        item.setNote("This is the first item");
  72:        items.add(item);
  74:        item = new Item();
  75:        item.setTitle("Item 02");
  76:        item.setPrice("15.00");
  77:        item.setQuantity("7.50");
  78:        item.setNote("This is the second item");
  79:        items.add(item);
  81:        return items;
  82:     }
  84:     public static ShipTo getShipTo() {
  85:        ShipTo shipTo = new ShipTo();
  86:        shipTo.setName("Customer 01");
  87:        shipTo.setCity("City 01");
  88:        shipTo.setCountry("country 01");
  89:        shipTo.setAddress("Address 01");
  90:        return shipTo;
  91:     }
  93:     public static ShipOrder getShipOrder(ShipTo shipTo, List<Item> items) {
  94:        ShipOrder so = new ShipOrder();
  95:        so.setOrderid("Order number 01");
  96:        so.setOrderperson("Order to Person 01");
  97:        so.setShipto(shipTo);
  98:        so.setItem(items);
  99:        return so;
 100:     }
 101:  }


As you can see, is quite easy, serialize as de-serialize the XML with Xstream.

The framework is quite small though powerful and easy to use, make it as one excellent option.

Monday, 13 September 2010

A Few Things To Take In Consideration Before Start One Agile Project

For my experience, that is more than twenty years in IT, and since beginning did try do some sort of Agile (beginning in 1991), when the project wasn’t big and one mix with Waterfall when with Enterprise solutions. Today by experience I’d know that is quite possible develop Enterprise solutions using Agile though a lot of things has changes since when. Especially with IDEs that 15-20 years ago where nearly inexistent, my preferred editor was the NE the good and old Norton Editor in DOS and  into Unix and Xenix  (if you do remember this last one, you should be considered a Dinosaur from IT, just like me!).

Must have more items to thing about it, though those ones for me are like the basics ones and will explain each one here. I know that some people may will say, “Aaaahhhh the number one isn’t true, the number X isn’t too, or even that this guy doesn’t understand about Agile”, however the truth is that I’d never have delivered one project with delays and the conclusion you should be take for yourself.

One thing for sure I’m not. I’m note that guy who want use EJB X, or Spring and bloat the system with patterns when isn’t needed. I like to talk technical language, though when talking with Juniors, is better you do use some examples with some sort of analogy that they will understand quite better. Be technical is good for who can understand, for those ones that are just starting, is one little bit scaring you be too technical. I think that they should have time to get there, and the first thing in one project that they need to know is, ‘know’ what they have to implement, and that they have one team leader that will be a team leader in fact. Teaching and explaining things when they need, they must feel that you are like a friend, that they can ask you anything about the project, language, patterns or correlated things without fear to be ridiculous. Doing this for sure they will have one better production and will close the gap about the system and those technologies involved.

You for sure should manage the code creation and have some patterns or conventions about it, and let your team familiarized with it as soon as the project starts. Comments exist and make then use it, explanations are never enough. This will help a lot when someone have to enhance or update the system.

If enhancing/updating or even maintaining one old system, to just create new classes and methods when strictly necessary, even that the code is the real bad quality. If you have time to re-write it, cool do it, if not, keep with the strict that is delivery the system working well. Doesn’t creating unnecessary classes and methods believe or not make the production go fast and doesn’t change the system structure, even being a bas one. Because, may be the next one to ‘touch’ in the system, will be the creator or someone that has to read follow all steps that you did to understand it and if you starting changing it, for sure the system will become a Frankstein and for sure will be harder to maintain.

One thing that I always put as top priorities are those two ROI and Quality, that means delivery good code and working of course, and that match with what the client expect and that has paid for.

Now for you that doesn’t have enough experience making run one Agile project I do enumerated a few things that should help you. 

1 . Just juniors will never able to work with/implement it.

   Nothing against them though if you are the only Senior in the project, be ready to do a lot of extra hours and have to re-write a lot of code, not all juniors are equals, but most of then take long time to delivery something. So  if you want make it go right since beginning mix at least one rate of 1 to 1, that means one with experience and one junior. If you can’t do that, don’t put the project and yourself in risk, go for some sort of mix, or something that is there before, keep one backup that can help you when you do need at most. Most of juniors must be guided, due this they love RUP and any Waterfall, because take off their hands the responsibility.


2 . Only years and having worked in several projects will give you the expertise to make run one successful Agile project, the same way one senior struts developer will never be a good system architect.

    This means that rush to be something that you are not ready to be, will just make you frustrated, saying that Agile does not work, like I’d saw a lot in several places on internet. If you don’t have any expertise with it, try create pilot projects, easy things to implement and try keep some sort of back up in whatever methodology was there before. With time you will be able to start spotting the issues and the potentials source of problems and delivery have solutions for it. Usually even reading a lot you will struggle in your first projects. If at anytime you don’t feel secure, raise the flag and call for help, it’s better you be honest with yourself and with is paying you than wast time, money and probably  lost your job. This also means that if someone ask you something that you don’t know, keep the head up and say that you will research about it and soon will let he/she know about it.


3 . The team must have the 'I can do it' attitude and be a experienced and organized team (this is one of the most hard to put together).

     This is a must in Agile projects, if any person of your team is showing you be one little bit lazy with lack of this attitude, talk with him a few times, though don’t expend too much time if you feel that he/she doesn’t want to change, take he/she off from the project fast. You can see this for the meetings, usually in the beginning of the project I do those very short meeting every day, after some time when they are familiarized with each other, I do go for one maximum of 3 meeting weekly, though most of projects one or two weekly are more than enough.


4 . Just follow what the book does not help if you don't have a good experience.

     I think that doesn’t need explain too much this right. If you don’t have enough experience and just try follow one book, you are putting a lot of things in risk, and one these include you, that depending of where you are trying implement it, you can kill your career before even started.


5 . Does not exist one standard way to make run Agile projects though just conventions, good practices, nor formula.

   As do wrote here before, your experience and being successful in find the potential problems that will make you run with success one Agile project.


6 . Use TDD with average team, will not help, you'll need a good team.

    Try follow it, if not TDD, test a lot your system in all possible ways, fail gracefully if inevitable, pay a lot attention with those nulls pointer exceptions, test those business rules up to exhaustion,don’t be lazy and try ask for some team mate test your code, when you do test other code. Check the data’s, create Unit tests, for everything that you had created and if possible one that will perform all tasks one full process. Try keep more realistic possible those data’s that will help you spot any issue easier than with auto generated data’s. After has tested for data’s do loading test and performance tests. Those ones will give you one good idea of how many connections your system can handle, the maximum before fail, and memory used.


7 . Need have access to the people that have the knowledge about what is being developed, no access means lack of information and fail.

    Without access to those ones that have the knowledge about what is being developed is waste time with Agile, don’t do it, because you will create one system that just get close, or not of what your client need and with quite less documentation, that means if he/she want make those changes to make the system match with what they expect, will be quite hard, and even you not being there anymore they will blame you for sure. My opinion is… “Always leave leaving the door open for you”. No ones can have the next day as granted right!


8 . At last one person of your team must have expertise in all project phases, like from make the interviews up to deploy in production environment, and know most of configurations for the environment to be used, just code does not help.

    This is very important, if you don’t have this expertise don’t do it or find someone that can really help you when you need. Remember Murphy’s Law… “If something might go wrong… it will go wrong”, and probably this will happen when you less expected.


Because this, isn’t so easy implement agile in medium to big projects and it's expensive for the company have several good guys working with it, and means that after project done, they will need keep a few just to enhance the system after, or to do the maintenance.
Before start one project you should know at least these points before to decide for what methodology you should go.
Of course there are successful histories in all methodologies, though doesn't mean that it will work all the time, and one very important tip for you. If you fail, please keep the head in place, keep calm, and do the analysis of what went wrong and why, to do not repeat it next time.

These are a few tips that I’d use very often and hope that it help you when you’d need it.