What's a software developer to do...

I don't know. When I read Brooks' Mythical Man Month (1972/1982/1995), or Kernighan/Plauger's Elements of Programming Style (1978), or Kernighan/Pike's Practice of Programming (1999), I get the impression that good programming practice hasn't changed nearly as much as the computer press wants us to think. In writing programs as in writing essays, the important thing is that you have something to say, and that you think it through. The languages, frameworks, and paradigms are important, but secondary. And who needs fancy frameworks when you have Emacs anyway?

But maybe that's just me being afflicted with FreeDuck's ideology fatigue.

You are completely mistaken Thomas. Programming is not art, it is technology. There is a big difference.

The goal of programming is to solve problems within a set of requirements. There may be some "artistic creativity" in the UI layer, but most technology problems deal with doing a specific task within a set of requirements.

Writing essays is a terrible metaphor. A better metaphor is building a house.

There is an surface element to building houses that contains some "artistic creativity" particularly in the area of aesthetics.

But the technology for building houses has greatly improved over the years. We have better tools, better materials and better design practices that allow us to build houses (or software) much better quicker and cheaper. Building a house today the way we did 100, or even 50 years ago would be foolish. It would be more expensive for a lower quality result and maybe wouldn't even meet modern safety codes.

There is a reason houses don't have thatched roofs any more and new materials and building techniques have been developed to replace them. And, there is a reason that Singleton classes are being discarded for dependency injection.

That's your opinion, and you're welcome to hold it. I don't.

That's not a very good way to have a discussion, Thomas. What are you disagreeing with?

I am working on a web application that manages and transfers data in a way that is very useful to our clients. There are a very specific set of requirements with the goal of creating greater efficiency. We also need to be able to add new functionality due to changing requirements quickly.

The Spring Framework, specifically the MVC design pattern and dependency injection, make this kind of work much faster, easier to test and more robust. There is a greater advantage in that using conventional frameworks allows me to pick and plugin ready-made components.

For example our application had a proprietary data format. One customer wanted JSON. Five years ago this would have meant weeks of work hand coding a way to transfer all of our data objects into JSON. With MVC and a ready made JSON view, we didn't have to do any thing except wire a new View bean and add a couple of lines of code in the controller.

I can say from experience that new technology and design patterns make it possible to do many tasks in significantly less time.

I'm not really trying to have a discussion. I simply have a different mental model for thinking about software than you do. Mine works for me, I'm sure yours works for you, so why argue? But since you're asking. . . .


I'm not familiar with the Spring framework, so I'll take your word on its benefits. In my worldview about software, though, the progress here is that the authors of that framework thought more clearly about the problems you're solving than their predecessors did. To reflect their improved thinking, they came up with new idioms, new turns of phrases in the Java language. But the framework they ended up publishing is the result of progress, not the cause of it. As I said earlier, it's about having something to say, and thinking it through.

My point is that in the past 5 or 10 years there have been great advancements in software development. Many areas of programming have remained the same. Sort algorithms are still sort algorithms and clean code is still clean code.

Many of the advancements have come in the area of design, for example in the area of making different components work together. Dependency injection, for example, provides a simpler way to organize how different parts of a system with different functions can work together with an added advantage in that components are easily swappable. Once component can be replaced without affecting the other components.

The new understanding of good design has been shown to be more efficient and easily to code particularly for software that performs multiple functions like modern web application, . There is research showing these principles increase productivity and lower bug rates.

The frameworks build on the new understanding of design principles. Dependency injection is proven to be a great idea, but it requires an infrastructure to support it. Spring (and many other frameworks) provide a ready made framework that engineers can build on top of. Building a dependency injection technology from scratch instead of using existing technology would be a great waste of time.

The principles drive the frameworks. But modern programmers and development teams make use of the frameworks for the same reason that older programmers started using compilers. You don't technically need them, but doing modern work without them is foolish.

Let's be utilitarian about this. Assuming the goal is productivity, meaning lowering development time and cost, and robustness, lowering the number of bugs after a project is released, there are practices that work better. This is a research driven field.

Have you looked at Software job listings lately? Companies are looking for people with an understanding of "Agile development", "SDLC", "ORM", and frameworks. These things didn't exist 10 years ago and are now nearly essential for a software engineer to get a great job.

There is a reason for this. Companies believe, with reason, that these technological advances will give them better results with less cost.

There may be other reasons for making software. But when it comes to productivity and robustness, best practices are the best practices for a reason.

Max, I really don't mean to brush you off. But when I said I'm not here to have a controversial discussion about programming paradigms, I really meant it. So I won't.

Ok. I was hoping to find someone to talk about trends in software engineering with. I think the discussion about whether and why they are useful is an interesting one. But if you really don't want to discuss it, that's fine too.

Well, since this thread is mostly dead, posting the story of Mel: the last real programmer seems appropriate. I hope someone finds it amusing.



Entire legend is at

http://www.cs.utah.edu/~elb/folklore/mel

If you are in software and haven't read this epic tale, you should.