I really like productivity tools. I want to develop software faster, I want to work less, I want to release software fast. Unfortunately, there is a mindset that cares only for (initial) speed and productivity at the expense of everything else. Those developers rush to finish fast and are very proud of it. They'll code in 2 days, what you code in 5. Sure, they don't have tests, the 'architecture' is at most MVC and the software 'just works' (well, you know... bugs but what software is perfect anyway?) Changes mean patching/hacking things together and it's all natural that everything will become a complicated mess, it's software development, it's expected to be hard and complicated (really?!).
But nevertheless, they 'ship' the first version so fast, they're that good. Too bad that a software product is finished only when it's at the end of life. Finished software is dead software (found that bit on twitter) and I wholly agree with it.
You see, developing software is like running a marathon. It's a long affair and it does matter to first finish (not to quit or die on the way) then to finish first. In software, to get to the finish is to win. The developers I was talking about before are not marathon runners, they are sprinters. How many sprinters won marathons? None, unless they become marathonists :) But why it that?
Sprinters are very good are running very fast on short distances. They train for that purpose. They simply can't run at that speed for 40Km, the human (animal) body isn't built for that. They might sprint for a time, take a break, sprint some more and so on, but in the mean time it's still the skinny jogging person that will finish the race.
When developers rush for first release or 'to finish' the software, they simply don't care about the long run. It's all now and that's it. Great for things you don't care about, but very bad choice for software you know it's gonna be used for some time, will change and worst of all, YOU'll be maintaining it.
You need to be a marathon athlete. You don't rush, you are going 'slow' (by sprinter standards) but steady. Your work needs to allow you to stay in the race, that is to allow you easy changes. Fewer bugs too, less bugs => less fixing => less breaking. And it's always more fun to code new things than fixing a bug variant for the 58th time. Going steady and not hurrying allows you to keep your sanity, to focus on producing higher quality code which means less boring work.
Fast and productive is cool but quality influences your future work and the question is: can you maintain your speed for all the product's lifetime? If you're fast only at the beginning then you slowdown to a crawl, how do you think you'll be perceived? I think lots of people will say that you are slower, not focused enough, you got older(!) or you don't care enough anymore. Few people will congratulate you for your 'old' productivity, they'll likely say that you were shallow and did a poor, rush out job and that's why you and your team struggle today
Managers and clients always want the work done yesterday, they'll praise you for being fast. They'll also forget instantly about it, when bugs appear or changes take long to implement. It's in your best interest to do a proper job from the start. Productivity is welcome, rushing is not. Design and code your app for the long haul, not just for tomorrow. It will be easier and faster for everyone, especially you, the one who actually has to do the job. Respect yourself and make your job easier, it matters the most to finish the marathon.