sábado, 13 de outubro de 2012

The best approach to software development in general

Methods, hype, fashion? See post at Crafted Software.

"... the vast majority of developers react to all these things. It is not just because someone, somewhere wrote a book, recorded a video or gave a talk in a conference about something that it will make that thing right, in all contexts"

See also Does that thing you like doing actually work? Quote: "I am, of course, asking whether there’s any evidence in software engineering

Super programmers

Practical ideas on programmer productivity

Buy x Build (software)

Great quote from DeMarco in the very well analyzed post The Buy-vs-Build Shift (part 1):
In 1982 Tom DeMarco opened his hugely influential book on Software Engineering with the line “you can’t control what you can’t measure”. Interestingly, in an IEEE paper in 2009[2] he writes: “For the past 40 years [...] we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”

However, he thinks that framework are a good substitute for a components market, which looks like it make sense until you realize that using a framework means loosing the universal machine paradigm. Loosing the programmability.

On the other side, I fully agree with him when he writes that "It seems that even if software development was not a core competency for most companies it is rapidly becoming strategically important for many to make software development a core competency."

The halting problem

A different - and good for teachers -way to look at and explain the Halting Problem: Eric Lippert's blog.

Complex things are complex

But not complicated. People should understand that anyone can program a simple enough problem. Developing a complex system is another thing. It requires skill and knowledge. You are building a machine. This is the point made by MarkCC in yet another excellent post in his Good Math, Bad Math blog: Everyone should program, or Programming is Hard? Both!
"To write complicated programs is complicated. To write programs that manipulate symbolic data, you need to understand how the data symbolizes things. To write a computer that manipulates numbers, you need to understand how the numbers work, and how the computer represents them. To build a machine, you need to understand the machine that you're building. It's that simple."