20. October 2012

Observation of software system: Starting with idea

Idea. Idea is starting point for life of software system. Pure raw idea and vision of future able ignite spark of hope that new software could work.

First stages of system evolution are very vulnerable. Idea need to form protective shell from enthusiasts who are helping to grow it. Idea also needs power and resources to survive. Enthusiasts must form some form of protective structure. It could be startup.

Idea is safe for the time being. It starts growing and eating more and more resources.

Time is passing. Enthusiasm is depleting. Dwindling resources could barely support life of idea.

Key turning point. Idea must transform into system which is able to sustain next phases of its life. It must turn into the system which is able to acquire new resources. Sell or bankrupt.

Luck, serendipity or deus ex machina. Somehow it starts selling. Early adopters begin to emerge. They like new system. They sense that it could become something great.

Idea is adapting protective its shell. Startup is no longer viable solution, because original enthusiasts are nearly exhausted. They spent many many hours and sleepless nights to push this idea forward.

Idea is transforming startup shell into company shell. First it is small, but it is growing.

Transformation will take some time. Software system is growing and consuming more and more resources. Balance of income and consumption is critical for survival of idea.

Maintenance. Software system has been around for several years. Idea prospers. New things were introduced with blinding speed, but this is slowing down over the time.

New changes in software system are causing pain. Idea doesn’t like it.

Idea must protect itself and its system. New defensive processes will emerge. Idea is able to deflect all dangerous changes with carefully designed processes.

System continues to grow and attract more resources. It is obvious that everything is ok.

Unfortunately entropy in software is growing. Hidden. Protected. Old parts of system are becoming legacy.

System starts to deflect even good changes by making them hard to implement. Legacy became so big that there is no way around.

Even minor changes must be introduced with careful precision of surgeon. Adding just one line of code to the system could take several days.

Legacy became burden. Development processes are slowing down. Maintenance is burning tremendous amount of resources.

This is a deadly trap. There is no way out. For some companies it is true.

One approach could be to set aside very high amount of resources. Develop wast change and then deploy it in one BIG STEP. It seems to be right! Welcome to booby trap.

More reasonable approach is to diverge small amount of resources from maintenance furnace. Remove clutter and legacy by small steps in the time. Keep a steady flow.

 

26. February 2012

Rigid specification vs. anticipation in software development

Software engineers love exactness of computing machines.

Developers often ask for detail specification in order to implement feature according to customer expectation.

It’s impossible to create 100% correct requirements. Customer “moods” are changing and it affects requirements.

Developers are puzzled when requirements are changing every day.

Software engineers were implementing exactly what was written in requirements. The next day they have to adapt to new requirements and half of previous work is nonsense in the context of new day.

The question is: How to face change in requirements?

One way is to put everything into requirements, build protective walls from corporate processes and invoke bureaucratic machinery against any deviation from predefined path. Defend current status quo at all cost…

Then you better start swimming or you’ll sink like a stone
For the times they are a changing

What is the other way? Use anticipation and imagination. Build the software in adaptive fashion. Prepare it for change.

How?

The first step is to admit that requirements are incomplete and that it does not mean that they’re bad.

The second step is to see a bigger picture and to find understanding for customer behavior.

Anticipate rather than react.

 

28. August 2011

Software Feature Paradox

By adding more features you'll achieve less.
By adding less features you'll achieve more.

Why is this paradox so common in the Sea of Software development?

It’s easier to add more than to add less.

It’s easier to rush than run for a long distance.

It’s easier to promise castle in the air than build it.

It’s easier to blame old code in the system than find understanding.

Is it harder to write test before a code than fix a bug within a bug within a bug?

­čśë

19. May 2011

┼Żilina – Conference – Open source in research and IT solutions

OSSConf 2011

You can find more details at OSSConf 2011 web page.

28. April 2011

Is your software Battlestar or just a soap opera?

Daniel Markhman wrote interesting article Sofware: More Battlestar, Less Gunsmoke.

Do you find your software product as something that has beginning, middle and end? Something that provides the value with story.

Yes? No?

There is also other option. Do you find your software as just another part of never-ending soap opera with same old story in different faint washed colors?

 

20. April 2011

Productivity in software project drops at least to 1/2 after handover

It is quite clear that productivity in software project will fall down “little bit” when you hand over the project to somebody else.

New team does not have all the knowledge of original author and it takes longer time to solve project issues.

The problem is that this loss in productivity is not quantified and project managers relay just on some fuzzy feeling.

I found interesting talk given by Audris Mockus about Digital Software Archeology. He made deep research in the topic of productivity in software development and he defined several useful terms.

Audris formulate very interesting result of his research: Productivity after handover dropped to 1/2. This is quite important to realize. It affects project planning and resource allocation.

 

11. April 2011

OpenBSD song: The Answer

Play: [wpaudio url=”/wp-content/videos/song49.mp3″ text=”OpenBSD 4.9 – The Answer”]

You can find out more about this song at OpenBSD release song page.

19. February 2011

When Agile becomes Fragile

I found very interesting recording of panel discussion with four IT professionals about Agile testing.

They are: Lisa Crispin, Elisabeth Hendrickson, Antony Marcano and Dietmar Strasser.

They’re talking about agile development and their experience with agile methods.

Do you wonder when Agile could become Fragile? ­čÖé Listen carefully.

Video is located at borland.com.

19. February 2011

Software travelers

Bas Vodde mentioned very interesting technique in his interview for SE-Radio.net. He call this technique travelers.

Let’s consider scenario: product development reached the end of iteration. Teams delivered results. People learned quite a lot. Some of them have very specialized knowledge.

Let’s give opportunity to people with very high technical knowledge to choose their team for next iteration. Give them the badge of traveler. They can choose where they want to travel in the organization.

Some of them will stay. Some of them will enjoy traveling between teams.

This technique can improve flow of knwoledge inside organization.

Software traveler is definitely not a new idea. Companies with wise management are already doing it. What I consider as very important is that Bas Vodde gave it the name.

You can download very good episode of podcast with Bas Vodde from Software Engineering Radio – episode Large Agile Software Development. I really enjoyed listening to this episode. Bas was talking about many interesting concepts in software development and agile.

Bas Vodde and Craig Larman wrote a book with title Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale SCRUM.

Note: You can follow SE-Radio Twitter – @seradio.

  • Where’s the fish?

  • Translations

  • Further info

  • Twitter

    Follow @jurajmichalek on twitter.

  • Comments

  • Tags

  • Topics