Usually we depend on third party software and services to complete our tasks. Also we depend on customer’s feedback to complete milestones properly. We need to identify our dependencies as weakness, and probably an obstacle to complete our goals. If you cannot manage your schedule properly, because you still cannot identify your dependencies, probably you will need to do an extra effort identifying them.
The classic example is when you send a budget, you get its approval from your customer, you setup a schedule, and you begin to waste your time because you did not identify a dependency correctly. The customer did not send you the document?, The system design was not delivered when the project was started?, The customer begins introducing changes into the project?, There is a leak on service availability?, The customer do not have the proper license for a required product?. You must realize that your project is delayed and you must reschedule it.
If you use milestones, it is easy to setup dependency lists and then identify which dependency can generate delay on your project, specially those dependencies that are related exclusively to your customer, since all of them do not have another meaning that makes to possible to reschedule the project. The same applies to third party software, services, and anything related to your needs to complete your tasks. All of them are related to the answer to the simple question “what do I need?”.
If you don’t reschedule the project, you will probably use more resources and more programmers to complete certain milestones, or the same ones, but using overtime, and probably generating more bugs than you can handle, delivering low quality software. That will lead you to fail. Probably you think that delivering the project on the schedule is cheaper, but it is not, due to the amount of bugs that you will find on software made under “monkey patching” or “quick and dirty” premises.
a short story
A simple story is as follows. I was working on Big Company. I was always facing the failure of Big Company services, such as SOA, message queue, and related services. Everyone was conscious about that issue. The leak of service availability was a pain for all of us — I think that it still is a pain. The dependency on those services is a well known dependency, and the leak of service availability was always playing a role against the project schedules and — in some manner — generating bugs indirectly.
As you know, I’ve propossed to create an object mock library, that shall be using XML configuration files to store the object mocks, instead of coding the mocks. That is more easy to handle and allows you to create a repository of well known mocks. That could elimiante the dependency on service availability, but the idea was practically ignored. Instead of building that software piece, I was assigned to fix bugs in other projects, so the time assigned to the mock library — which was 1 hour per day — was practically null. The mock library was never completed.
Few months from that try, I was assigned to another project on Big Company. I was facing two major problems: the leak of a stable network connection and the leak of service availability — again. I was sharing a network connection, and I was able to connect my laptop to the Big Company network only 15 to 20 minutes per hour. If the day was lucky, I was able to connect at least 8 times with only 10 minutes to debug and test. An average of 5 connections per day and 10 minutes to debug and test for each connection was delaying the project, but it was not rescheduled. The idea of service simulation has reborn then, everyone was liking to see all unavailable services to being emulated. But wait!, I must deliver a project and I must create a mock library at once!. The resulting library was not the XML mockup library, it was an object capture and serialization library that was storing objects on the hard drive once they were created. So, I’ve tried to capture service provided objects, and was hard with that kind of connection to retrieve all objects required on that project and I was developing the main project simultaneously.
The result was buggy software and the cost was higher than expected. The managers were seeking the guilty on that failure, and obviously the guilty has fall on me. I still have copies of those emails sent notifying about the leak of service availability and the leak of the proper network connection. I really cannot mind what is in the head of those managers. I still can remember the golden question “why you did not emulate those services?”. Emulate the complete set of services? From the login service to the required services? Knowing your dependencies is a must, and solving them to remove them as dependency is vital.
That time, they call me with various adjectives that I do not want to remember. I prefer to think that they are working with very skilled people that can supply them of the same or higher level of knowledge and professionalism. Someone that accepts passively what they see as real :)
Entries 