Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Why this page?

I've spent 31 years working in the software industry, I've so many drives and running after 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.

  • Mid 80s developing medical systems in assembly on CP/M machines, no real structured approach, but definitely incremental development
  • Mid towards 80s developing medical systems in dBase II+ and Clipper, no real structured approach, but definitely incremental development
  • Late 80s developing medical systems in dBase II+ and C++, a waterfall approach, but definitely incremental development - a forward thinking company
  • Just heading into 90s developing medical systems in C/C++, a formal waterfall approach was being applied and it was not incremental, get it right once and no looking back (not a good experience). It was also during this time that I came across Object Modelling Technique by James Rumbaugh et al, this is the point where my whole approach to software development changed. I realised that you create good software by doing some upfront design. Now I know a few of you out there are thinking "yeah I do that but I just don't write it down." And that's where the problem is, you don't write/capture what's going on in that crazy mind of yours. I suddenly realised that if I could capture what I was thinking in a consistent, agreed and proven way, then the next time I need to come back to the same problem I wouldn't have to spend hours or days trying to figure out what my code was doing and what the heck the problem was that I was trying to solve in the first place (sorry ranting....). Remember - we didn't have the version control systems that we have today and neither did have the test techniques that we apply today.
  • Early 90s developing communications software in C++/VB, used several languages for designing - OMT, Booch, Shlear Mellor, Syntropy
  • Just prior to the mid 90s developing distributed object systems using CORBA in C++ with some Java starting to stream through, OMT the dominant design language, iterative life-cycles became the norm (the fountain approach)
  • Mid 90s, UML and Java beginning to replace OMT and C++ as the dominant design and programming language respectively. So for about 4 years worked primarily on projects suing these Java and UML.
  • Just after mid 90s world goes crazy and we're in the throngs of analysis paralysis. Basically it's a waterfall approach being applied to OO techniques. It ain't working. We have teams of analysts creating mountains of documents that have no correlation to the software being developed. Software developers think analysts are idiots and analysts think software developers should stay in their caves. It was an interesting time to be a software developer and designer.
  • Late 90s the emergence of XP and whole family of other OO styled techniques trying to solve the problem of analysis paralysis. But most of the techniques come into view for a while then we fall right back into that waterfall cycle. I worked as technical architect in the rail and tube industry, architecting and designing many of the systems for London's TFL Oyster Card.
  • Early 2000s, technical architect for a major upgrade of London's TFL Victoria Line. A none OO project but clearly defining the architecture and design of the components upfront was crucial to it's success.
  • 2005 for about two years, an advisor to the UK NATS on the architecture and suitability of technology and architecture for a proposed solution to a very important infrastucture project.
  • Since 2007 I have been an architect, consultant, advisor and software developer (C++, Java and C#) on numerous projects.
  • So what I'm about to write I do so from a reference point of immense experience.
  • 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.
  • No labels