Back from vacation.... During the holiday season, I had some time to read a couple of non-IT books, like Le bourgeois gentilhomme (The Middle-Class Gentleman). Molière wrote Le bourgeois gentilhomme in 1670. A key part of the play is when Monsieur Jourdain, the main character, discovers that he has being speaking "prose" all his life without knowing it (verse was more popular than prose at this time).
When I started my career as a software engineer (97), I used to consider myself as a lousy developer. I worked first with C++ and PoweBuilder before focusing on Java projects. No matter what the programming language was, it was always the same story. I had problems writing lines of code based on a written specification, while my colleagues seemed to be very productive. They were spending days coding features with no assistance, without even compiling their code. Remember that we are in 97-98. C++ and PowerBuilder are not interpreted languages, and the software specification is very often a verbose document. And most software development processes are waterfall.
My way of working was quite different. I used to write a few lines of code, to compile and test it immediately in order to verify that......it was not working as expected (usually with some ugly runtime error). Then I was refining the former piece of code to fix the error, and I was repeating this again and again until I was able to complete my tests successfully. Typically, I needed to test and rework my code several times per hours. Comparing myself to my more experienced teammates, I was ashamed of being such an ineffective developer.
Also, it was real difficult for me to apprehend the specification written by the business analysts. I was usually understanding the big picture, but not enough to be sure of the right piece of code to create. At this time, I was convinced that it was a result of my lack of experience. My colleagues seemed to be satisfied with the features assigned to them. They were working in isolation with just a specification document to help them.
Again, I had developed a specific technique to compensate for my inexperience: I was buying coffee all the time to the analyst team. I used to spend a lot of time (and money!) at the coffee spot with them, in exchange for their explanation. It was quite an expensive way of obtaining meaningful input, but I guarantee it helped me decipher the cryptic specifications. And after a few months, my regular “coffee discussions” were far more helpful than any document.
A couple of years later, I realized that my way of working was aligned with some agile practices. Just like Monsieur Jourdain, I was being agile for some time without knowing it. My daily (and expensive!) talks with business analysts, developers or DBAs were actually quite productive. And it was not uncommon to continue the discussion at my desk so that I can demo something. The different stakeholders were all providing early feedback to the feature I was trying to implement. And with my countless tests, I was actually improving the quality of my code, iteratively.
On the other hand, my teammate working in isolation were creating software disconnected from the business needs. End at the end of the time allocated for their development, they have never tested their code. What I was (jealously) seeing as an impressive way of writing code was actually a poor practice.
I am pretty sure that there are a lot of Monsieur Jourdain around us. Practitioners who leveraged agile practices far before agile became popular.
The good thing is that because agile is now mainstream, we no longer have to buy coffee for a discussion with stakeholders. Now it's part of the process, ..... for free.
Pragmatic Architecture, DevOps, and Cloud Computing
Matching: agileadopt X
There are a lot of myths around agile software development. Agile teams need no discipline, no documentation, no planning are some examples of the misconceptions about agile. Here I want to share about two other myths regarding architecture and agile practices.
Myth #1: Architecture is not an agile practice.
Some say that agile teams don't waste time on architecture, they focus on coding the solution. This (false) statement is often made by people convinced that architecture has been intentionally banned from agile methodologies.
Of course, this myth is completely false. I checked my IT bookshelf for concrete proofs. I found specific recommendations for architecture on agile project from various agile though leaders such as Scott Ambler, Ken Beck, Alistair Cockburn, Mike Cohn, Ron Jeffries, Robert Martin, Mary Poppendieck, and James Shore. Check the recognized agile references. You will learn about architecture.
Myth #2: Agile teams don't do modeling
So myth #1 is declared busted: architecture is part of the recommended agile practices. And architecture is not only refactoring and test-driven development. Agile teams also conduct modeling activities.
Conclusion: Let's be pragmatic. As agile teams, we have to think about the structure and the behaviors of the solutions we develop. And very often, simple modeling sessions are very efficient to build better applications. Architecture is definitively a key activity of agile developments. It helps teams teams build better software-intensive systems.
jl.marechaux 060001NWA6 Tags:  sketch tools rsa rational agile featured agileadopt 7,998 Views
Experienced Agile teams working on software-intensive systems conduct architectural analysis activities to mitigate technical risks and build better solutions. As a picture is worth a thousand words, those teams leverage diagrams for better agility. It is really efficient to share ideas and lead brainstorming sessions.
To create those diagrams, I can use a napkin, I can prefer a dashboard, or I can choose Rational Software Architect V8 (RSA) sketches. Why would I use RSA? I could think of four different reasons: easiness, collaboration, documentation, and flexibility.
Reason #1: Easiness
RSA sketches are easy to create. There is no learning curve on RSA sketches. They use simple and informal notation, just like I do when I draw a diagram on a whiteboard.
Reason #2: Collaboration
Whiteboards are good, but not good enough when you need to collaborate with an extended team. How do you share your draws with people you collaborate with. The project stakeholders, the clients, the remote resources? Ok, you can always take a picture and share it. But what happens when you need to work again on the diagram later? Do you try to work on the picture file or you create the diagram again. It is not really practical nor efficient.
With RSA, you create sketches, you have them in your repository, and you can use them anytime, even through a web conference. You can collaborate efficiently with your local teammates and with external stakeholders. And of course, you can modify the sketches over and over again.
(I will write another post soon on how you can collaborate a step further with models on a shared repository)
Reason #3: Documentation
I know, documentation in Agile projects is not popular. We need to focus on working software. But this is where RSA sketches are useful. I create them, they are stored in my repository, the history of changes is kept. It is the basis for light documentation. I can focus on my development activities.
Reason #4: Flexibility
What can I do with a sketch on a whiteboard? I can look at it. I can erase or add elements. I can take a picture of it. And that's about it.
Now what can I do with an RSA sketch?
I can of course look at it, or add and remove elements. I can save it as a picture file (see, no camera needed this time).
I can also arrange the sketch appearance applying predefined or custom layouts (grid, hierarchical, horizontal....). This is always a challenge with a whiteboard diagram. You start the drawing and when you need to add more items, you have no space. Then you start writing so small than it become difficult to read.
With RSA, I can also link sketches to other sketches. Or create sketches form sketches elements. Then my diagrams are linked together, and a simple click opens the source or the target element. Really convenient to brainstorm at a high level first, before creating more precise diagrams for the most complex part of my solution.
Another nice RSA option is to convert my sketches into UML elements. So if I am using UML in my project, I can start with informal sketches and convert them when I need a more formal notation. Traceability between sketches and UML models is automatically created. I can even decide to mix informal sketches elements and UML elements in the same diagram.
RSA sketches are easy and flexible. They can support my Agile development and enhance my team collaboration. For further information on RSA sketching capabilities, see the free agile sketching training component on http://goo.gl/wGYtF.
jl.marechaux 060001NWA6 Tags:  featured agility-at-scale pragmatic rational tools architecture agile agileadopt 22,968 Views
\'prag-me-ti-zem\: a practical approach to problems and affairs.
In software engineering, architecture is a concept difficult to define precisely. One word is used for very different concepts such as functional architecture, data architecture, solution architecture or enterprise architecture. In addition, boundaries between architecture and design are unclear. Some say they are similar concepts. Others argue that they are complementary concepts with different levels of abstraction.
The real question is not what architecture is or is not. The real question is whether or not architectural analysis is useful for your project. And most of the time, if your are developing software-intensive systems, the answer is YES. It is where pragmatism comes into play.
Many methodologies try to define the architectural work that you should complete. Some fundamentalists recommend that you define your architecture before you start your development. Dogmatic theoreticians say that architecture is a waste of time and that only code matters. Pragmatic architecture is about adopting the approach that works best for you. And what is best for you is not necessarily what is best for others.
The pragmatic architect focuses on essential concrete tasks and prioritizes the work according to the value it brings to the project. The pragmatic architect is open-minded and never refuses to consider a solution just because it is not the trend of the year. The pragmatic architect revisits the design as the development of the system progresses.
Your goals during p.r.a.g.m.a.t.i.c architectural activities
As architects, we must value pragmatism and practical experience over dogmatism and theory.