There was a time, long ago, when programmers were forced into a highly disciplined way of working, because they had no option. Whenever writing an application of any size, the programmer needed to think first of a way to test and monitor it. Then they'd have to develop all three aspects together: monitoring, testing and the application itself. If they were slightly odd, like me, they'd document it too, at the same time. Most of all, they had to learn the language they used thoroughly. Why all this hair-shirt behavior? There was no Integrated Development Environment.
SQL database development has resisted the worst excesses of the Integrated Development Environment, but even in SSMS, it is possible to just produce the code without any thought about the test harness, or for recording performance. It is just too easy to rely on all the wonderful props and supports: graphical execution plans, comparison tools, DMVs, reports, debuggers, and so on. Once you've got the hang of it, you can just program in a strange state of consciousness, somewhere between sleep and wakefulness.
How could there be any possible disadvantage to an IDE that bristles with prosthetic aids? Firstly, because system designers were once constrained from the urge toward ever increasing complexity by the imperfect memory of the person doing the programming. Now, with IntelliSense, Professor Google, and online help, it doesn't matter: you can chuck in complexity by the spade-full. Secondly, nobody thinks about how to make their code testable, and how to monitor it, unless forced. If programmers are no longer compelled to build a system that tests and monitors itself sufficiently well to enable them to determine where performance problems lie, and work out strategies for fixing the problem, then they are at the mercy of the tools with which they are provided.
I love the ease of laying down code in SSMS and VS, of course, and use all the toys when I need them, but often I prefer to work without the clutter, as I find it forces me into the habits of monitoring, testing, documentation and strategic thinking that the IDE allows me to avoid. These habits have other paybacks. They feed into other parts of the process in many ways, some of them subtle. They make life easier for operations and for team-based tasks such as issue-tracking and hand-over. Compliance and audit can be easier, and test teams will positively smile. They force you to really learn the technology in depth. Sure you can compensate with such disciplines as code reviews and TDD, but IDEs are like sugar. Great in the short-term, but leading to dependency, and long-term complications.
Phil Factor.
