CRYPTOCHAOS

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all. 

These are the people I call Architecture Astronauts.

The big secret is requirements traceability. Each and every architectural decision must be strongly derived from forces (i.e., requirements and risks). This also helps to keep the architecture simple, expressive and balanced, because this way we can get rid of all these design pearls smart developers and architects typically invent.

Applications have a natural tendency to grow. If you don’t pay attention, what started out as an elegant, simple application that perfectly solves a single problem, can quickly turn into a huge behemoth of an application that solves a ton of problems, but solves all of them poorly. Features are always more complex than you think, and many small features quickly add up to one large mess.

“Elegant”, that is an adjective that is often used to describe the Python language. The term elegant is defined as “pleasingly graceful and stylish in appearance or manner”. “Uncomplicated”, and “powerful” could also be great words to assist in the description of this language. It is a fact that Python is an elegant language that lets one create powerful applications in an uncomplicated manner. One may say that if you look at trends that are occurring within the computing industry today, Python can be looked at as the main objective. There are dozens, if not hundreds, of programming languages available today which each offer a different flavor to the field. Although there are many flavors, there is a similar objective for each of these programming languages...and that is to produce powerful and uncomplicated code that is easy to construct and maintain. Python does just that.

Interesting...

It happens over and over again. I visit a team and I ask about their testing situation. We talk about unit tests, exploratory testing, the works. Then, I ask about automated end-to-end testing and they point at a machine in the corner. That poor machine has an installation of some highly-priced per seat testing tool (or an open source one, it doesn’t matter), and the chair in front of it is empty. We walk over, sweep the dust away from the keyboard, and load up the tool. Then, we glance through their set of test scripts and try to run them. The system falls over a couple of times and then they give me that sheepish grin and say “we tried.” I say, “don’t worry, everyone does.

Make sure you go to the link and read the entire post. I generally agree with the points. We're headed in this direction with a new project and luckily the packages we're looking at provide API's into the application that the UI uses. We'll be able to automate many tests without directly going through the UI. But... the UI must still be tested thoroughly and UI testing tools are required.

Code is king

If you’re in a semi-technical job, you absolutely need to look at the code. You don’t have to be able to write it or debug it but you need basic code literacy. Sync the source tree and get it building. If you can’t figure out how, ask around (and get to know the dev team in the process). Look at the daily checkins...

Another gem from Martin Fowler...

Ambiguity is unfortunately one of the consequences of standards development - the larger the spec and more complex the task at hand, the more potential points need to be nailed down, so a certain level of ambiguity in a working draft simply indicates that it is, well, a working draft. However, HTML 5 is seemingly being pushed inexorably towards recommendation status with most of these ambiguities still intact, with almost no community feedback (beyond the half-dozen or so committee implementers) and with remarkably little rigor being applied to what is, without a doubt, one of the most important potential specifications to emerge from the W3C in a long time.

Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect.
...
“At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

Although I don't always agree with Joel, this column is spot on...