Home » Author Archives: Gil Zilberfeld

Author Archives: Gil Zilberfeld

Rebooting ALM, Part IV: Fantasy

software-development-2-logo

 This is the final part of the Rebooting ALM series. You should also read: Part I: Evolution Part II: Power Part III: Weakness We’ve covered where ALM tools excel, and where they falter. Now, allow me to fantasize about how we can take a leap forward and start solving actual problems for real ALM users (that’s us). Most of our work starts ...

Read More »

Rebooting ALM, Part III: Weakness

software-development-2-logo

This is the 3rd part of Rebooting ALM series. You can find the others here: Part I: Evolution Part II: Power Obviously, I wouldn’t call this series “Rebooting ALM” if the tools didn’t have their weaknesses. Let me count the ways. The first problem of ALM tools starts with the customer. The end-user  of the system (developers, testers, business analysts) is NOT ...

Read More »

Rebooting ALM, Part II: Power

software-development-2-logo

This is the 2nd part in the Rebooting ALM series. Check out the first part “Evolution“, to see how we got here. (See what I did?). The first tool, I think, that started the ALM tool chain, was source control. There were compilers, and some IDEs, but source control systems were solutions for team-work. If you think about it, the ...

Read More »

Rebooting ALM Part I: Evolution

agile-logo

This is the first in a series about Rebooting ALM. I’m going to present this next at Agile Slovenia in a week, don’t miss it. I’ve started thinking about how Application Life Cycle Management has changed over the years. It’s funny, because what’s the first thing they teach you in agile class (I hope)? “Individuals and interactions over processes and ...

Read More »

You Can’t Build An MVP

software-development-2-logo

MVP is an acronym for Minimum Viable Product. Ever since the Lean Startup book and movement appeared, it has become the staple of “successfully building the right product”. It’s pretty clear, right? Minimum – it contains just the needed features that enable us to make money. Viable – people are willing to give us money for it. Product – It’s sort-of-a-tangible thing ...

Read More »

Letting Go Of Technical Debt

software-development-2-logo

The term “technical debt” was first introduced by Ward Cunningham as a metaphor. It was in the early 90s, when the rift between developers and business people was growing wide. The business people would urge developers do release untested, ugly code. The developers tried to explain why this was a bad mistake. (Not like today, right?) The metaphor of debt ...

Read More »

Help Professional Developers Survive

software-development-2-logo

A developer’s life is not simple. Developers need to contend with adding new software features, quickly, from different customers, while keeping up with technology. And do some support work in the middle. And, also meetings. However, the road to improvement through this complex situation can be a strange one. It sometimes starts with these suggestions, heard around in recent retrospectives: We need ...

Read More »

The Story with Story Points

agile-logo

I don’t like story points. I think this is part of my crusade against complexity. You can catch a glimpse of  it here. Story points were invented as supporting beams for the bridge between business and development that would later be called agile. They started with a very good concept that wasn’t there before: The story. Remember those hundred page specs, and ...

Read More »

Estimates: Jumping To Wrong Conclusions

agile-logo

The main dysfunctions we concentrate on when talking about estimates are how they (and the people who gave them) are treated once they are given.  Management asks for estimations and then either: Disregards them completely and sets a deadline that ignores the estimates, made by the people who actually know and will do the work. Inflate them because “they are always late”. ...

Read More »

How To Make The Most Of Failure

software-development-2-logo

I was asked a hypothetical question: If someone caused a major failure to the business, would that be a reason to fire her. I said no, because:               It is unlikely that a single individual can actually be the only accountable person in such a scenario. If the error wasn’t malicious, that makes the failure a ...

Read More »

Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Advanced Java Guide
  • Java Design Patterns
  • JMeter Tutorial
  • Java 8 Features Tutorial
  • JUnit Tutorial
  • JSF Programming Cookbook
  • Java Concurrency Essentials