| Info | ||
|---|---|---|
| ||
I've spent 31 years working in the software industry, I've seen so many approaches and methods and with each one we have frantically ran after each as though it were the silver bullet. There isn't one and don't let anyone fool you into thinking there is!!! But I recently ran some Unit testing and TDD training and was stunned by he questions that were being asked. It lead me to question the direction in which the software industry is heading. Before I rant like a crazy man let me qualify my journey to where I am today.
|
- For the last 15 years there has been a steady march of the agile brigade, the philosophy is great, the people behind it are all awesome, they're great OO designers and thinkers and have written many awesome books on OO and UML that I still have on my bookshelf. An important point about the manifesto is that it doesn't say there should be no documentation. It's abut striking the right balance.
- Now whether you doing waterfall or Agile, architecture and design are activities that still need to be done. The question I keep hearing is "if we're adapting an agile approach can we develop the architecture and design of our systems in an agile way?" Well why not? It makes more sense to draft out an architecture, take it the client, seek early approval, make changes as needed and repeat this until you have an agreed architecture. Notice something about the question and answer, when we are talking about the architecture, at level are we speaking, software architecture, systems architecture, information architecture, or an enterprise architecture? All of these things can developed in an incremental manner.
- Since the early 2000s there has been a rise in the desire the build software using TDD. Now TDD is a practice that we can used within your Agile lifecycle. But it is cleary about the development of software, not the design of the infrastructure, the QoS attributes of a system as a whole, the security requirements, the evaluation of technologies required for the entire solution and their costs, it doesn't reveal data transformation issues and I could go on, the list is big. These are architectural and design issues that must be tackled early and refined on an ongoing basis. Once you have your architecture, TDD can be applied at the component level.
Guys you would never build a house or anything of significance without talking to an architect or asking the question what's the foundation, whether it's a brown field or green field
Architecture is birthed out of experience
An Architecture is a collection of collaborating patterns
Architecture sets the direction for everything else
Architecture captures the vision
In an IT environment the architecture can evolve incrementally but (and it's a BIG BUT), you will always find that there is a core architectural footprint from which everything else gravitates. There is a core set of functional components that represent the architecture and even though the architecture evolves those components remain consistently present throughout the evolution of the architecture. You will see such examples as 3-tier architectures, master-slave architectures, dual-redundancy systems etc. In the same way that software patterns can be categorised as either structural, behavioural, creational etc, as defined by GOF, these same patterns and more exist at an architecture level. Also, architecture is more than just patterns, it has to consider security, costs, hardware, people, usage, scaleability, maintainability, testability, how do you protect the investment, means of distribution, vendor selection, development approach and the list goes on...
So can you really do the above in a TDD manner? I think not. Incrementally yes to some degree, TDD no, no, no!!! Software is only one part of the architecture stack.Follow these two links to see why I'm going to rant about some of the questions that I have recently had thrown at me
| Info | ||
|---|---|---|
| ||