Successful project management with Liquid Planner

I was told recently there is a certain inflection point a company reaches when it gets to about two employees. I certainly experienced this inflection point this year, w.r.t. dealing with projects and tasks. I decided to implement LiquidPlanner around Q2/2013, and am very happy with the decision.

(Note: I am not affiliated with LiquidPlanner in any way, none of the links in this are affiliate links, this is my own impartial opinion.)

The Problems

  • I didn’t get the feeling the customers really knew what was going on in the projects. I would often be called upon to give status meetings, send email status updates, etc.
  • I didn’t get the feeling the employees really knew what was going on. I kept task lists on paper (had worked for me when I was working alone!). I would occasionally send these lists via email. This required time to do, and these emails would slowly get out-of-date, so it wasn’t obvious for the employee what to do.
  • It was difficult to answer questions such as “If Martin works less, what effect will that have on the launch date?”
  • Also questions like “if the web designer gets delayed, what effect does that have?” (Certain tasks must get delayed, but for tasks where screens have already been done, they can get moved forward)
  • “If we add a new feature, how will that impact the deadline?”
  • As a consequence of not being able to easily answer the above questions, this had the knock-on effect that decisions, which could only be taken after knowing this information, couldn’t be taken.
  • Despite the above, I spent a lot of time doing project management! (21% of my time in Jan, 36% in Feb, 40% in March)

The Solution

Clearly there is enough information on the LiquidPlanner homepage for those who are interested. And there are other features such as time-tracking and financial estimations of remaining work which I am not using. But here are the key points regarding how I use it.

  • One one view, as a project manager, you have a hierarchical list of tasks and you can set attributes of those tasks, write comments, estimate them, manage dependencies, assign them, and so on.
  • On another view, as a worker, you just see a flat list of all your open tasks, ordered by their priority, and you can just work through them, estimate them, assign them to someone else, comment upon them, etc.

Here are the points I think are necessary to my workflow, and which LiquidPlanner does better than its competition:

  • Task durations—Either the project manager or the worker themselves can estimate how long tasks will take. Some other systems simply have lists of tasks but without being able to enter durations, it’s not possible to ask questions such as “how long will the entire project take?”
  • Duration ranges—You can enter “this task will take between 8 hours and 12 hours”. These allow you to enter not just your estimation but also your uncertainty (will it take 1h-8h or 6h-7h?). This is combined using a statistical model to estimate the duration and uncertainty of the final project deadline. Only FogBugz and LiquidPlanner could do this as far as I could see.
  • Dependencies—It seems to me than any project I do has some dependencies: the front-end only once the back-end and the HTML is done, HTML only once the Photoshops are done, Photoshops only once the requirements are done. This needs to be modelled, so you can not only see what tasks are ahead of you, but which you can already start on now. To estimate the completion date, you need to know this information as well. Many systems don’t support this, such as trac and basecamp.
  • Critical Path analysis—I can select any task, and say “show me the critical path”. This takes into account what tasks an employee must complete before they can complete the given task, and also any dependencies to tasks which must be completed by other employees.
  • Tasks can be organized hierarchically—I always got annoyed by systems like “trac” which just had a flat list of tasks. Each time you looked at your tasks they seemed to be in a different order. I find hierarchically arranging the tasks in a tree-view much more convenient.
  • A living plan—At least at one of my customers, I go to their office, there is a huge multi-page MS Project Gantt chart on the wall. I’m sure they’re proud of this chart, I’m sure it took a long time to produce. I’m sure it “feels” like they’re doing good planning. But they’re not. This plan doesn’t get updated. It’s irrelevant as soon as it’s printed. A central cloud system gets updated as new tasks are found to be necessary (e.g. bugs), and as old tasks get done, perhaps faster or slower than they were initially estimtaed to take.
  • Update remaining hours (not % through task)—If you’re half way through as task, you can update the system with “I worked 4 hrs, I have 6-8 hrs to go”. I prefer this to saying you’re 50% through the task, which necessarily refers to the original estimate, which is almost certainly going to be out-of-date now that you know more, now that you’ve worked 50% of the task.
  • Online—I want to have a single place everyone can log in and see the state of the project. Thus I don’t need to compose emails telling everyone the current state, and the customer saves money by not having to pay me to do this. This discounts tools such as MS Project.
  • Part-time employees—I can enter the fact that most of my team work e.g. 30 hours or 10 hours a week. It takes this into account when predicting the end-date on projects based on the effort remaining.
  • Provides information, doesn’t take decisions—I know best who can do what, etc. It doesn’t provide any facility to “balance” work e.g. by re-assigning something from one employee to another.
  • Email notifications—This seems like an obvious win, and most task tracking systems, e.g. Redmine, offer the facility to inform people when things happen. However, there’s a big difference between doing this right, and doing this just mediocre. If a person updates a ticket a few times within a few minutes, Redmine sends individual emails, LP sends only one. If you alter something yourself, Redmine sends you an email about it anyway, LP does not. After one weekend I literally had 200 emails in my inbox (using Redmine), which doesn’t inspire one to read each one carefully.
  • Reply to email notifications—If you get an email from Redmine, and reply to it, it just gets lost. If you reply to an LP notification about a task, what you’ve written becomes a new comment in the task. This allows people who are “tool-averse” to still be part of the conversation.
  • @Mentions—If you are writing a comment on a task, maybe you want to mention someone. Simply refer to them as “@David” in the text and they’ll get an email. (As above, they can reply to the email and what they wrote will get added to the task as a comment.) In this way you can bring people into the conversation, and keep the knowledge in a system visible to the entire team, and away from individual inboxes.
  • No “priority” or “importance” field—I don’t like it when you have to say “this task is high priority”, “this task is medium priority”. Everyone uses those statii differently. (Or worse, when one has to enter both “priority” and “importance” fields! That difference is subtle, which everyone understands differently.) In LiquidPlanner there is just a big (hierarchical) list of work. The work higher up in the list gets done before the work lower down in the list. You are free to rearrange this order as you like.
  • No drag & drop of task bars in the Gantt chart view—Some tools allow you to take a task and drag it to the left to mean you’ll do it earlier. I don’t know why you’d want to do that. In LiquidPlanner you state the order of the tasks, and their estimates, and who will do them (and it knows how much that person works), and LiquidPlanner tells you when the task will get done.
  • Customer Portals—A customer of mine can log in and only see their projects, incl their tasks, deadlines and estimated completion. Nevertheless, my employees are shared between various customers (if Martin is working on X, he can’t be working on Y). The scheduling happens across all customers, however each customer sees the information relevant to them.
  • Not all task visible on the Customer Portals—A checkbox per task allows you to specify if this task should be visible on the Customer Portal. For example “Add new field” is something the customer cares about and understands. But “Investigate NullPointerException in log” is perhaps not.
  • Good employee onboarding—There is a nice 5-minute video which explains to employees how to use the “my work” section, perform estimates, and so on.
  • Convenient time tracking—On Redmine, to record hours, you enter a number into a text field. You are obliged to use Excel, or a piece of paper, to record when you start things, so you know how long you’ve taken. With LP you freely right-click on any task and click “start timer”. If you were working on another task, the timer for that task gets suspended. In this way tracking your time becomes effortless: no Excel needed.
  • Checklists—If a task comprises of many steps, it’s too “heavyweight” to create individual tasks for them. In LiquidPlanner each task has a list of checkable items. For example, I use these to record bugs I encounter as I’m developing a feature. In other tools I add “comments” with bulleted lists, but it’s difficult for other people to get an overview of what’s done and what’s still to do.
  • WYSIWYG editing—If a business guy is to create a task, I don’t want to explain a new markup syntax to them. Rich text boxes with buttons like “B” for bold have been around for 20-30 years. LiquidPlanner supports such a rich text box, other systems such as Redmine do not.

Conclusions after 9 months

LiquidPlanner has found good adoption by my team, and has solved all of the above pain points. It has excellent customer support. We are happy with it and continue to use it. However,

  • Expensive—At $29/month/user, which for my 3-5 users, quickly escalates to €100/month, and the months go by and suddenly you found you’ve paid €1k. If there’d been a piece of software offering a one-time license fee of €1k I would never have bought it; yet now I’ve paid more than that, and the total amount spent keeps on increaseing each month.
  • Some have not adopted it—Some customers, and people they manage, were unwilling to adopt LiquidPlanner. They prefer to work with other systems, and keep me out of the loop. As these have no estimation abilities, questions like “when will we be finished?”  cannot be answered. As long as I have no visibility into the tools I cannot manage the project (although it’s my job to do so.) This is a political problem, not one a product can solve: the customers don’t want to feel like they lose control. I don’t think LiquidPlanner, or any other tool, can solve this. As long as the customers wish to pay me for weekly meetings and writing emails about status, then I suppose I shouldn’t complain too much, even though they’re acting against their own interests.
  • No undo—If you make a mistake, you’ve got a manually revert it.
  • No VCS integration (git, Subversion, ..)—This is not a feature I have really ever used in competing project management systems but I know that other people do.
  • No Wiki etc—I know other solutions such as Redmine come with an integrated Wiki. Honestly I think such a thing has no place in a project management tool. One can just install a Wiki separately. But no doubt there are those who disagree, so it’s worth mentioning.
  • SaaS only—There is no option to download and install LiquidPlanner on your own servers. This might make it the wrong solution for sensitive data. I think that the NSA won’t gain access to many trade secrets by seeing my task list. But I know others disagree. FogBugz would be a good choice in that case.
  • Timesheets only record duration—When I bill customers I like to show start/end times of each piece of time I’m billing e.g. “2pm-4pm=2 hrs”. But LiquidPlanner only supports recording the number of hours done, not at what time they were done.
  • No collaboration on estimation—Someone (anyone) can update estimates of tasks. There is no facility to say “three people think it’ll take 5 hours, one person thinks it’ll take 1 hour, so the system determins it’ll most probably take 5 hours”.
  • No resource balancing—I am working with small teams of 3-10 people. I know who is the most appropriate worker for what task. (Workers can also claim work themselves, if I get it wrong.) However, working with 1,000 person teams, one would need a facility to say “I need 100 software developers, who are available, who ideally have this skillset”.

Business 2013

This is a report of business activities in 2013. (Similar to the report for last year, 2012).

My employee MartinL (software development) has remained with me for most of 2013, although returning to university in the latter half of the year. New employee DavidZ (software development) has joined.

I have been getting into outsourcing for a few years. Not for the obvious reason of reducing customer costs (that’s just a side-effect), but for the fact that good people in Vienna are often already engaged. I don’t want to have to tell my customers “We can do the project, but only in 6 months..” so I’ve had to look for other alternatives. We’ve had some good and bad experiences (as it to be expected), but now I have at least one person who delivers excellent quality and is very reliable.

I have diversified away from just software development into doing project management, requirements, photoshop and html, javascript. This has been made possible by my extended team.

I have also started to do basic websites, based on WordPress. This is not the most lucrative line of work, and I’m not sure if it’s a good direction to go in, but it seems to be what the market demands. And I don’t like to say “no” to customers :-)

A sadder note in 2013 is that I’ve started to use KSV (debt collection agency) to collect money from some of my customers. It seems there was a lot of unwillingness to pay by some of my customers (not all!). Henceforth I shall be taking a harder line; any customer with any debt will not be able to order new features at all (even if they are very persuasive salespeople).

We have taken the following software online for our customers 2013:

  • firstbird has been architected and programmed by myself and the team. This was a major undertaking, over 1.5k hours of effort. Companies can post job openings, Employees of the company can recommend people for the jobs. Companies can rate and hire candidates. Employees are kept in the loop all the time via feeds and various email notifications. Employees get points, monetary rewards and badges for their efforts. Information posted and captured from Facebook, XING, LinkedIn and Google Contacts. PDF CVs automatically generated from XING and LinkedIn information, etc.
  • mobilreport imports mobile phone bills and analyzes them. We have 40+ paying customers; big companies in Austria and Germany with large phone bills covering up to a few thousand employee mobile phones. We take the call log data from the mobile provider and parse them. Often these are very nasty formats, e.g. CSV files where certain cells contain unescaped “,” characters, i.e. parseable only by heuristics. The operators have no desire that you parse their data, apply learnings from it to save yourself money. So they’re not keen to fix such bugs. We now support the following formats: A1 AT (EGN and 2 Landline formats), COLT AT Landline, Telering AT, T-Mobile AT, T-Mobile DE (CSV and EDIFACT), Vodafone DE (EDIFACT).
  • For one major customer in Austria we extended mobilreport with the facility to calculate employee limits (i.e. employee gets a phone from the company, may use up to €20 per month, the rest gets deducted from their salary; bosses may use up to €100, various calls don’t count). They are informed about their limit exceedance via SMS.
  • mobilreport now has the facility for employees to log in and see the calls they’ve done with their company mobile phones. SSO from the company’s intranet to our system means the employee doesn’t have any extra passwords to remember.
  • Demonstration for a major Austrian vendor of a “command and control” center for police, with various projectors, controlled via iPads. A “game” was described in XML (firstly this scene, then if the user selects “send car” then this scene..), this is parsed on the iPad, commands sent via XML over HTTP to VLC instances connected to the projectors. Used web-technologies; written in GWT by MartinL and myself.
  • Extended a PHP system, back-end for an iPhone application for authorization and location tracking, with various pieces of new functionality (DavidZ)
  • Matchmatrix event site (alas the event was a failure so website was taken offline and I was never paid; case is with debt collection at the moment.)
  • Calendargrads website was implemented in WordPress for under €500 (logo was not done by us)

Jetty doesn’t show errors on web application start-up

From a certain version of the “jetty” package in Debian Linux, if the web application didn’t start up (servlet init() throws an Exception), this error wasn’t logged anywhere. The solution is to install the libjetty-extra package.

sudo apt-get install libjetty-extra

It took some amount of experimentation to find the solution. I don’t know why you’d ever want to not log errors; i.e. why the logging of errors is an “extra”.

Jetty is a Java web server, similar to Tomcat, it’s my server of choice. It’s simple, doesn’t seem to do much apart from run WARs, and (apart from this issue) I’ve rarely had any problems with it.

Wrapping IDs in objects

In Java, I like to wrap ID values in objects, rather than just passing them around the code as their native “int” or “long” or “String” values.

The reasons are twofold why using an object is better:

  • Code becomes more readable, for example foo(LoginId x) is more readable than foo(long x). (Although perhaps neither foo nor x are good names, so perhaps the example over-exaggerates this improvement.)
  • The compiler can do more checking. If you pass a job advert’s id (as a long) to a function expecting a login id (as a long), the compiler cannot warn you of your mistake. This becomes particularly relevant if you have a function taking two IDs and you pass them the wrong way around.

Things to consider when writing such an “ID object”

  • Do not allow the ID contained within the object to be null. Having “LoginId x” where x is not null, but the value contained within x is null, makes no sense. (For example, use primitive types if dealing with numerical IDs, as they cannot be null.)
  • If the ID is a string, don’t allow this string to be empty; same as above.
  • Implement equals and hashCode methods so that these IDs can be used within Sets, or as keys within Maps, or as keys in Wicket drop-downs, or wherever.
  • Make them serializable.
  • Make the ID attribute a “public final” attribute. That means useless getter methods can be avoided, from the object itself and from client code.
  • The object should have a single constructor which takes the value and sets it in the attribute.
  • Implement toString so that the debugger can display the object usefully.

“New Game!!!”

I am writing this blog post in October 2012; this will get published automatically in one year, like government secrets published 50 years after the event. But this just cannot not be shared.

One of my flatmates has just written an email to all:

Subject: New Game!!!

It’s time for a little Game called… … …  “Clean your dishes and live in peace” !!

Few assertions:

  • Human being has to live in an hygenic place
  • Everyone is respectful
  • Time to:  putting your plates, glasses, cutleries in the dishwasher + clean by yourself pan, saucepan(Yes, because as you know hot water is expensive and Earth ask us to do not waste it)  =  takes no more than 5 minutes
  • A clean kitchen is an area where everyone can go and enjoy it (because currently it’s not really welcoming)
  • Live in a sharing flat is also comply with basics rules

If anyone is not interested about this “game” we are all enough mature to talk about it.

Also, if anyone has a request to do : It’s time to do it !!

The person who was implicitly addressed in this email wrote back, also to all:

Hey. We kind of established a “policy” that its ok to let dirty dishes lie around for 24 or even 48h at certain occasions. At least no one ever had a problem with that, as long as its not getting to worse.. I personally think that maximum 1 or occasionly maybe a few days is a good timefraime to have and would not like to be forced to always clean everything right after eating. Sure we are mature enough to dicuss this.

How happy do you reckon the original author is going to be with this reply??

Made a mistake? Have a pay rise!

The following two viewpoints are not consistent:

  1. “Come and work at our company. We are looking for someone with lots of experience. The more experience you have the more you’ll get paid!”
  2. “You made a mistake. You’re fired!”

You can pick up knowledge at university and through reading books. But companies still want experience in addition to knowledge. For me, experience is very much having seen what works, and what doesn’t work, by having done things that work, and done things that don’t work.

So in my opinion, if you’re going to pay someone joining a company a higher salary if they’re more experienced, if your existing team member walks in to your office and states “sorry I just made a mistake, my bug wiped the production database”, you should reply, “congratulations, this is one mistake you won’t make again, now you are more experienced, have a pay rise”.

For those who don’t know me, it’s worth pointing out that the above is not intended to be 100% serious. Nevertheless, I think the principle stands, that, assuming you’re basically good at what you do, making a mistake increases your experience and thus generally increases your value to your employer.

Sunday was quite a day

On Friday I learned that I must create a website for a customer, and that P.R. was going out about the website’s existence Sunday evening. On Saturday I was out all day at a wedding. So Sunday was going to be the day when it was both going to be started, and had to be completed.

Amazingly, my colleague Mae and I did the website in the day. Mae designed the entire HTML from scratch. I found out how to integrate with PayPal, and implemented the API during that day: including using the IPN notification API to register successful payment and decrease the number of tickets that were available (limited guest-list to an event.)

It’s a website where you can sign up to the MatchMatrix event; it’s an dating event taking place in a Vienna club in August, limited to 250 places for men and women.

Let’s see if the event is successful, but Elmar Rassi, the event co-organizer, has over 100k likes on Facebook, so must be pretty famous. [Update 29 Jul: No tickets were sold; website is offline at the request of the customer]

Mae is one of my remote workers from the Philippines who I found over the internet. I like to work with remote workers, as it increases my capacity, i.e. I can deliver more work to my customers that way. I would increase my team size in Vienna, but people who are good are already employed.

Although my and my team’s speciality is software development for websites, every now and again I get a request to just make “a website”, without a lot of software. I’m happy to do these projects as well. Although, ideally not on quite such short notice.

If you’re going to change databases, do it in one go

At Uboot, there was the suggestion that we should change database technology. This was because we would save money with by moving away from Oracle to e.g. MySQL.

It was further decided, as we had 200k+ lines of code, and 100+ tables, that if a migration was to occur, it shouldn’t happen  “all at once”, but instead one would have some parts of the system migrated with other parts of the system not yet migrated.

But the strategy of migrating databases piece by piece has the following problems:

  1. Data consistency. Initially, all important data are within the source database. It is possible to guarantee certain consistency constraints (e.g. all photos are owned by existing users). However, if e.g. photos are migrated to MySQL, while users remain in Oracle, no such consistency can be guaranteed. Inconsistency has the consequence that software must accept not only valid data, but also invalid data. It is impossible to test the software for all combinations of invalid data, and with the rule that “software which is not tested does not work”, one can deduce that the software will then not work. The set of inconsistencies will increase over time, so the set of users who experience bugs will also increase over time. Afterwards, going from an inconsistent state to a consistent state is nearly impossible.
  2. Reporting over multiple system areas. With one database, one can ask a question such as “how many photos belong to users logged in in the last month”. A “SQL join” is used. However if the tables reside in different database, no such query can be asked. One would have to export the data from one database to another, in order to ask the query. Or export all data into a centralized data warehouse. Or write software to do what a single line of “join” would do. All this effort is saved, by using a single database.
  3. Point-in-time recovery. With one system, if the database crashes or an error is made (e.g. “drop table account” is executed by an employee), a “point-in-time recovery” can be performed. Data is restored to its consistent state as it was at a certain point in time. If one uses more than one database, a point-in-time recovery will be more difficult. For example if the databases are out-of-sync by 1 second, then some photos will exist for which there are no users, or vice versa, and data consistency problems exist as described in point 2.
  4. Spending money on migration; no saving in license fees. If a migration is done, time/money is spent. Not only in doing the migration, but fixing performance problems after the system is done. If money can be saved on the Oracle license, perhaps this time is worth it, however if one is using multiple databases then one is still paying for Oracle.

The solution is either to change databases in one go, or simply don’t change databases. You want to have your data in one place, at all times.

Minimal security is gained by using case-sensitive passwords

My colleague suggested that systems should compare passwords in a case-sensitive manner. He pointed out the larger space of possible passwords, and thus the longer passwords would take to crack by a brute-force attack. This is all standard knowledge.

I still maintain, however, as discussed before, that the correct trade-off between usability and security is to compare passwords in a case-insensitive manner.

The increase in usability in having case-insensitive passwords is obvious (and documented in the previous post), so to understand the usability/security trade-off, how much is security reduced by using them?

The following calculations assume the following:

  • The NSA, or whoever, wishes to attack you, has access to the hashed password (e.g. database leak)
  • They have a strong machine such as this one
  • They use a brute-force attack and try every combination (they don’t just use dictionary words)
  • Assuming you’re a person of interest, let’s say they are prepared to expend 2 months running the machine at full power just to crack your password
  • A case-sensitive password has 80 possible characters to choose from (upper-case, lower-case, numbers, symbols), a case-insensitive normalized password as described in my previous blog post has 54 possible characters.

So how long would your password have to be to defeat the above attacker, with case-sensitive and case-insensitive passwords?

SHA1 Passwords

The machine above can try 63 billion passwords per second. That means, in the 2 months available, it can try out 3.4×1017 passwords.

  • A case-sensitive password with length 10 has 10.7×1017 possibilities, so cannot be cracked
  • A case-insensitive password with length 11 has 11.3×1017 possibilities, so cannot be cracked

So the “lack of security” imposed by case-insensitivity can be mitigated by having a single extra character in your password, or, put another way, making your password 10% longer.

To those who would argue that it’s likely people will use random 10 character passwords but not random 11 character passwords: I propose that there are those of us who will generate n character passwords using a tool (the site is free to suggest n, meaning its value doesn’t matter), and there are those who would use their pet’s name as their password, in which case even a case-sensitive password is insecure, meaning case-sensitivity doesn’t matter either.

bcrypt(10)

But let’s try a more realistic example. Who uses SHA1? We use bcrypt, like presumably everyone else.

bcrypt has a strength parameter. It re-hashes the password 2n times. So each time you increase the strength parameter by one, it takes twice as long to calculate. By default this strenth parameter is 10, which is fine for us: it takes our server 0.1 seconds to calculate such a hash.

The web-page says that monster machine can do 71k bcrypt(5) passwords per second. So that means it can calculate 2.2k bcrypt(10) passwords per second. Meaning in the two months, it can calculate 1.1×1010 passwords. So that means:

  • A case-sensitive password with length 6 has 26×1010 possibilities, so cannot be cracked
  • A case-insensitive password with length 6 has 2×1010 possibilities, so cannot be cracked

So we find out that with a normal hashing strategy, the password doesn’t have to be made longer to remain at the same level of security.

The “lack of security” imposed by case-insensitive passwords mean that the password either has to be slightly longer, or not longer at all. The usability advantages are very real. So that, in my mind, makes the usability vs security trade-off a clear win for case-insensitive passwords.

When and who should fix bugs?

There are (at least) the following options that a project manager must make when organizing bug fixes to software:

  • Should the original author of the code in question fix the bug? Or should there be a “bug team” who surgically go in and fix bugs?
  • Should one fix bugs as one goes along? Or concentrate on features and write the bugs down and fix them in a “bug sprint”?

I am very much in favour of the original author fixing bugs, and fixing bugs as soon as they occur. Because:

  • It’s difficult to predict how long it will take to fix a bug, e.g. estimates might be “between 5 minutes to 4 hours”. It’s easier to see how far through the project you are if you have 50% of the features working without bugs, than if you have 75% with an unknown number of bugs each taking an unknown length of time to fix.
  • If a programmer makes a mistake, it’s important that they learn it, so they won’t make it next time. That’s why the original author should fix the bug.
  • Do you put your best programmers or your worst programmers on bug fixing? Bug fixing is tricky, so if you put your worst programmers on bug fixing they’ll only make the situation worse. If you put your best programmers on bug fixing, they’ll all quit.
  • If one person is maintaining one piece of code, they feel “ownership” over it. This is perhaps the opposite of the desirable quality that everyone knows the code. Nevertheless, I think “ownership” is a powerful concept that causes people to take more care of their work than they otherwise would, leading to a better piece of software.
  • Assuming that bugs are fixed immediately, and you find a bug in an existing part of the system, you’ll report it and/or fix it. If bugs are left until the end, and you see a bug, you’ll just ignore it, as you know there are existing bugs. This might cause a new/different bug to not get reported.
  • If you fix something weeks later, you might have forgotten the original code, including weird important speical cases. Ideally everything would be perfectly documented and readable, but that often isn’t the case in reality. Having the special cases in your head will prevent your bug fix from actually being an introduction of further bugs.

One of my old bosses used to utter the phrase “you break it, you fix it!”. I never had good associations with that phrase, every time I heard it, new pieces of work were only seconds away from being assigned to me :-)