Author: Tomasz Liberski

The toughest dilemma I’ve been dealing with over my past five years with a software consultancy house is “how do you make an agile project, or any project for that matter, successful with an inhibiting agreement with fixed key terms?”. Having tried various approaches, combinations of approaches and bending the continuum, I’ve arrived at the conclusion – “you don’t, and there is no way around it.”

Here are some lessons I’ve gathered over that period of time – about the projects that have been a success and had the same common denominator – a time-material agreement.

Trusting and earning trust

• let’s start small, or even very small
• let’s see after a week or two what both parties bring to the table
• let’s look back at that initial period and decide if we can work efficiently together

Playing for the same team and sharing the same goal

• both parties are vested in growing the client’s business
• mutual understanding that long-term success benefits both parties more than any short term wins on either side – this leads to mutual respect
• thinking in ROI categories by all people involved on both sides
• we love suggesting killer features – hey, at the end of the day everyone benefits

Minimum overhead

• no debates on what’s in scope and what’s out
• no debates on what’s a bug and what’s not

• no debates on what’s a bug and what’s a CR
• hey, no CRs!
• no development of features we don’t believe in
• no more waste!

Endorsing agile

• there can be no real agile with an inhibiting agreement underneath. Give your success a chance!
• agile is still the best approach to software development
• agile and time-material fit. No more artificial agile, calling it agile, iterations being just another name for weeks etc.,

Iterations and priorities

• you’ve changed your mind about your business direction – very well, we’ll play right along
• ”no offence, but the feature you’ve started working on is pointless now that the competition already has it” – “none taken, let’s build something they don’t have yet, and let’s start today”

Business driven development

• you show needs, we advise, you decide, we do it
• you need to grow your business in an optimal way, we’re there to help you achieve this goal even if it means taking a suboptimal route from the IT perspective at times

Longevity and sustainability

• long-term motivation based on a common goal achieved together in small steps, not on bonuses, management pressure, fear and contractual penalties
• long-term perspective motivates against taking intentional shortcuts that would remain unnoticed for a long time but are very costly when eventually TSHTF
• this model has a significant impact on team morale which leads to attracting new team members and inhibits departures thereof

100% transparency

• you get billed for the time we’ve spent working on your project. Every minute of it and not a minute more. No rounding up!
• pay for what you get. Time spent on our self-development, training, company meetings is NOT billed!
• if we think there’s a problem ahead – we tell you immediately
• if we don’t think the feature is worth spending time on – we tell you, you might reconsider

Actions instead of words

• PoC instead of multi-page specification and implementation documents
• PoC instead of estimations, negotiations and assumptions
• get an MVP ready and show it to the clients ASAP
• estimate you budget and milestones based on facts (real team velocity) not promises (initial estimates based on documentation)

author: Tomasz Liberski

Every software developer needs to check what’s under the hood from time to time. For beginners first choice will be naturally print_r paired with <pre> or “more advanced” var_dump. Even if there is nothing really bad with this solution there it can be done better.

Of course such approach may need additional effort to make it work but in most cases it’s worth trying to debug like a pro.

In this article we’re recommending Xdebug. This PHP extension will allow you to see what’s happening inside your app, check global arrays like $_POST or $_GET, look inside objects and watch which variables are currently set. Moreover – Xdebug allows to execute your app line by line and see what is happening during request.

As a bonus – Xdebug is good for testing ajax requests. Normally your endpoint is returning JSON or XML. When you use var_dump inside such output you will ruin document formatting and get an error in your JavaScript, which should receive and parse a response. Using debugger you just delay execution but after debug process output will stay untouched.

To start with Xdebug you first need to install and configure php extension.

For installation on linux (debian-based) systems you can use:

sudo apt-get install -y php5-xdebug

Then you need locate configuration file which can be found in:
– apache: "/etc/php5/apache2/conf.d/20-xdebug.ini"
– php-fpm: "/etc/php5/fpm/conf.d/20-xdebug.ini"

Base configuration of Xdebug which should work on any environment is:

xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.idekey = "idesecretkey"
xdebug.remote_handler=dbgp
xdebug.remote_mode=req

Depending on the IDE you are using you need to configure it as well.

If you see Fatal error: Maximum function nesting level of ’100′ reached you should set xdebug.max_nesting_level = XXX where XXX is nesting depth = 200 (or more) in your configuration.

Configuring PhpStorm to use Xdebug on dev environment

For PhpStorm which claims “zero configuration”, so it’s as easy as setting IDE Key and port (if needed – by sticking with the key “PHPSTORM” and port 9000 then it’s already done for you) and starting listening for incoming connections.

Procedure is well described on PhpStorm zero configuration Xdebug manual so there is no need to copy it here.

Additionally if you want to provide your own IDE key or change listen port just provide them like described here. There is nothing more to do. If Xdebug extension is configured properly and IDE key and port match those in Xdebug config, plus when you’re debugging external host-path mappings are correct everything should just work.

Configuring Netbeans to use Xdebug on dev environment

1. Setup general NetBeans properties in Tools → Options → PHP → Debugging

2. Setup project properties in File → Project properties
– select in left menu “Run Configuration” and check or specify your project URL

– click on “Advanced” button under “Arguments” field and select “Do not open browser”. In this case NetBeans will not open new windows after debug session will be started.

3. Select in project configuration in right menu item “Sources” and specify small and but very important configuration option “Web Root”. Click on “Browse” button and select the folder where your init php script is placed.

Start Xdebug session inside your web browser

Install Xdebug plug-in for you dev browser and configure idekey for remote debugging.

After this you should enable debug plug-in in browser, set breakpoint and start debugging session in IDE, refresh browser page. IDE (if listening for incoming debug connections) should handle debug session and will focus cursor on first breakpoint.

Mozilla: addons.mozilla.org/EN-US/firefox/addon/the-easiest-xdebug/

Chrome: chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

authors: Sergii Shostak; Bartek Telesiński