Master the unpredictable

Have you ever come to work on a Project that you cant quite overlook? Are Requirements not yet clear or changing fast? Here are some tips to get along.

Use Tracer Bullets

Don't specify your software to death. Just grab your best idea, and give it a shot. Tracer Bullets are similar to Prototypes with one very important difference.
Prototypes are built to proove something, and then be thrown away. They are not intended for real production. Even some drawing on a paper could be a prototype.
A Tracer Bullet might get thrown away, but it is not intended to in the first place. It is developed as stable, clean and complete as needed, to use it for real production. A Tracer Bullet that hits its target, becomes a trunk.

Develop Leaves first

What do i mean with a leaf? Leaves are small exchangable software components or modules, that can be written independently, tested in isolation, and sometimes even run autonomous. They only perform a very specific task, not more. Find the leaves in your Project, and start developing the leaf with the highest risk.

Dont Reinvent the Wheel

99% of the problems that you face in your project have already been solved. Solving these by yourself can easily become a waste of time. Even the most trivial seeming problems are not trivial at all. Underestimating those is the issue in the first place, nevertheless it happens all the time. Well, its just logical to understimate the unsolved as you cannot know all the details until you solved it yourself. Analysing the problemdomain, concepting and realizing a solution can be a great way to learn, but is not very beneficial. Its in fact a risk, since it can lead to misconception or become a timeconsuming task that exceed your resources. You might even have to throw away your first attempts. Also, your outcome would be buggy, whereas established opensource software is usually stable thanks to its brave communities.
"Make or Buy" was a common phrase. I think it should be "Make or Find" by now, since opensource got really big. Rather invest your time into research opensource, and stay skeptical with what you find. When you compare 3rd party software, consider
  • Stability: Is it still beta, or did it have some stable releases yet? Who is the organization behind? Is the code clean and tested?
  • Activity: Can you find out how many developers this software has? When was the last commit? How frequently do they release a new build?
  • Support: Does it offer a good documentation? How about examples? Is there a public Issue Tracker? How many issues have been submitted yet and how many have been solved? Is there a Forum, literature, and a big community? Are there any big names that use this software?
  • Critisism: Is there anything bad that you should know in the first place? Search for reliable critiques and comparisons.

    Estimation is a waste of time

    Every hour that you invest in estimation, could also be invested in producing real outcome. Your estimation will be inaccurate anyway. When requirements change, you even have to change your estimations. If you have to estimate, because the business needs it, try to split your Project into smaller independent Parts first, and multiply your estimation with a Risk factor (times two for example). In the end you`ll need it.

    Plan only the nearest Future

    Its not worth planning more, because it will change anyways. Existing Tasks will explode, go away or change. New unforseen Tasks will appear.

    Comments

    Post a Comment

    Popular posts from this blog

    8 Things you should not be afraid of as a Developer

    Change In Software Development there is no such thing as stagnancy. Everything you develop now is just another version of a component that will probably change in the future. Change is the most common thing in Software Development, and you're better of accepting it as a fact. Expect future changes to everything you develop, and therefor design your Code more modular. This makes changes more easy and increases the Quality at the same time. Adapt the concepts of DRY and YAGNI . You will often come to the Situation, where you look at your Code and imagine that you could have done that "better". Don't let this thought prevent you from sleeping. Take action immediately and Refactor ! If you don't do it now, you will probably never do it. The longer you wait, the harder and more costly it gets. And you slowly grow up a mess you cant deal with anymore. "Good code is code that is easy to change. Code tends to change until it is no longer easy to change. All code bec...
    Read more

    News

    So we just got back from a little Canadian weekend with Thee Oh Sees. We had a blast. There is a lot going on in our world at the moment so we've been a bit busy - sorry for the lack of updates here. We have a whole bunch of upcoming shows, check out the shows section to your right - these include shows with SEX CHURCH, a mini-tour with PYGMY SHREWS, a couple of shows with RUSSIAN CIRCLES, and a little European tour in December. If any of you euros cant make it to see us in December, we will be back in January for a little over a month, and we are very excited. We have a new LP done, it will be out in March on Sacred Bones Records and much touring in support of it shall follow. We have also been informed that Karmic Swamp Records is repressing the "Think" 7" that came out last year. There were only a handful of those pressed so hopefully people that missed out on getting them can grab one now. We will post here when it is available. Also, thanks to everyone who has o...
    Read more

    Why REST is so important

    Image
    This post is dedicated to REST, an architectural style of shaping webservices and the most misunderstood concept in the history of IT. This post is addressed to you who is designing webservice apis not being fully aware what REST actually means. I'm trying to give you the idea. This post is also addressed to you who think to know what REST means, when in reality you have no clue, just yet. Yes i have met such people in the past - plenty of them. It's not going into the details of the Richardson Maturity Model , and it's not gonna make you a REST expert. There are plenty of guides on the web for that: slides, youtube videos, blogposts, books and more. Rather than going into the details, i'm going to link some good resources at the end of this post. So lets start with The meaning of REST Representational State Transfer. This sentence is not only what REST stands for, it is also the tiniest possible description of what REST actually means. Didn't get it? Read it aga...
    Read more