I admit that I regard automation as a dull but vital part in the success of a project. Automation had evolved into Continuous Integration, a powerful toolset allowing frequent and regular building and testing of the code. I won’t get into what CI is (check the internets). Instead, I am going to explore a couple of aspects of CI that can be added to the artifacts of the development process and note some others that cannot.

Continuous performance
You wrote performance tests. You can run performance tests by firing a battery of tests from a client machine and targeted on an arbitrary environment where the application lives. The test results are collected on the client and you can publish them on a web server. Why not automating this completely then? To accomplish this, automate the execution, gathering and publishing of the performance results. Daily performance indicators not only increase visibility of the progress of the application but it becomes much easier to fix a performance degradation on a daily changeset than between two releases. There are a couple of factors that may add complexity to establishing performance tests:
Dealing with dependencies
The obvious rule of thumb is to minimize dependencies. However, if there still are dependencies on other (perhaps external) systems, use mocks and to isolate the system you’re testing for performance. We’re talking about nightly performance tests so don’t put unnecessary stress where you shouldn’t.
Finally, the main artifact of the final integration (done once per iteration) is a running environment where all components run together, in a production-like setup. Use this environment to run your system performance test where you measure the current performance against the baseline.
Measuring relative performance
The environment you’re using for the nightly PT cycle most likely will not be a perfect mirror of production (especially true when dealing with geographically distributed systems). Use common-sense to establish the ratio between the two environments then derive rough production performance numbers using it (assuming a linear CPU/Throughput relationship).

Continuous deployment
This is as simple as it sounds: automate the install. Make it dead easy to deploy the application in any environment by providing installation scripts. Simplify the configuration down to a single file that is self-documented and easily understood by non-programmers (read Operations Teams). The goal here is to unlock a powerful tool: making the application installable and upgradable with a click of a button. If all the other pieces of the continuum are in place then you could confidently deploy your application in production it on a much tighter release cycle, even on a daily basis. Deployment and integration become tasks in the background rather than first-class events.

More continuous
Since I am just fresh off the Agile Testing Days conference and I have learned a few more Cs from the distinguished speakers which I term as Soft Cs since they involve constant human engagement:
- Continuous learning (Declan Whelan)
- Continuous process improvement (Stuart Reid)
- Continuous acceptance testing (i.e. stakeholder signoff at the end of every sprint) – Anko Tijman
- Continuous customer involvement (Anko Tijman)

There are three forces that shape a project: domain, process and technology. Add the “-driven” suffix to any of them and you’ll perhaps recognize some of the methods used in projects you’ve been involved in and yet, as soon as one takes too much of a lead against the other two, failure will follow almost inevitably. At the intersection of these three forces we find familiar terms and concepts but first a word or two about each of them:

Technology
Back in the days of the tech bubble, tech was allmighty. Buzzwords like Java, EJBs, PHP defined entire projects. It was the time where software became accessible to a much larger audience. The new wave of enthusiastic geeks embraced everything from new languages to professional certifications to the then-nascent open source. I admit having my share of technology-driven projects back in the day…

Process
Process brings structure and pace to a project. The two complementary components of a project process are methodology and integration. We are all too familiar with methodology: waterfall, RUP or agile methods of software development are vastly documented and practiced; integration largely is defect management, testing, build, deployment and documentation. Today they all come together in what is called continuous integration where all these concepts become interrelated in a repetitive process that produces accountability and visibility into the progress of a project. Process is also the one force that tends to disappear first after a project is finished.

Domain
The domain captures entities and business logic, is driven by the business requirements and is in no way influenced by the two other forces. The most successful way to employ the domain is through Domain Driven Design where the main focus of software development is neither technology nor process but the business requirements.

There are times in the life cycle of a project where these forces have to be kept separate but most of the time they shape each other. At their confluence there are several artifacts that are paramount to a project’s success with code being at their core.

Code
Although each force is important during a project life-cycle, they all work towards producing code. No matter how many UML diagrams, software architecture documents or burn down charts are produced the most valuable and tangible value that a project creates is runnable code.

APIs
Application Programming Interfaces represent the external view of runnable software products. APIs state the intent of the software. They should be cared-for and refined during a project lifecycle, until they become the best representation of the domain they are modeling. APIs also serve for integration purposes and so they should be extended to blend into the domain of the consumers as needed.

Features
Features are defined within a project scope. They can be fully defined prior to coding in a waterfall process or, defined and/or shaped during the project development in an Agile setup. Features specify a system’s requirements (they are called user stories in an agile project).

Test, Build, Deploy, Run
Projects have to be monitored since inception to their natural end. Just like a child’s development stages, projects need to touch milestones, assess velocity and health. They do so by constant testing, building, deploying and running.

Roles
Project roles that drive each of these forces can also be mapped in the above figure. Take the Agile roles for instance:

A fine balance
Imagine any of the forces represented by circles in the picture becoming disproportionally larger than the others. As a result, one or more of the artifacts at the intersection of the forces will become disproportionally smaller than the others upsetting the equilibrium. Whether is less features, less APIs or less testing, the end result is still unbalanced.

As always, people (roles) will drive the forces. Balancing them requires skill from all parts involved and the success or failure of a project depends on giving enough power to each not to overturn the balance. If ancient romans could do it two millennia ago, so can we.

There’s an interesting story rippling the news stream these days: The New York Times is questioning the ways Techcrunch reports on news. The crux of the issue is product journalism v. process journalism, the act of producing news only after all facts have been verified versus just writing the story based on what the author best knows about an event at that moment then let the story evolve and provide rigorous updates and corrections once it does.

As I was reading, I got an epiphany. The “old media” is following the old methods, much like the waterfall process where the story (the requirements) has to be fully known before proceeding with actually breaking the story (the implementation). The new media follows a radical approach: it starts with a lead (or rumor) that is initially published in a somewhat crude form, then the story evolves based on field feedback and facts drawn from the actual reality, until it becomes accurate. Even the language of the aforementioned references use words like “iterative process”, “transparent” and “standards” the same way I’d use them when talking about developing software.

This method of early release followed by incremental improvements resembles so much the agile methods of software development, I’m calling it Agile Journalism.

A revolution is happening in the media. Old methods are swiftly pushed aside; the emergence of the Internet as the news dissemination medium is fundamentally changing the ways the reality is reported upon. Who wants to read a story that is already obsolete or wrong altogether and impossible to be corrected/evolved until a new paper edition is off the press? The new media not only breaks news faster (release early) but gets the stories right eventually, simply because the new rules (standards) are clearly stating that until confirmed, the product -otherwise useful- is still a beta representation of the reality and the consumers already know how to consume such product.

From blogs to real time news streams, the new media’s aspiration is to bring the most accurate information yet to the consumers. It can and will do it by revolutionizing the way the stories are iteratively discovered based on constant feedback, the same way agile methods are revolutionizing the software industry.

Image courtesy hirefrank

		“Thinking in…” anything has been a marketing quirk for a while now, being used and abused from the field of language learning to computer science. Thinking in Java is the title of a well known book written by Bruce Eckel. I am passing a “Think in Spanish” course flyer ad every time I stroll on Bloor Street West here in Toronto. Funny, thinking within the rigors of a discipline is the very definition of thinking inside the box. With respect to programming languages, it encourages one to think within the limits of a single language which is the exact opposite of what one should do when developing software.

The hegemony of agile methodologies inflicted a disruptive change on the face of the software industry and amongst the established roles within a team. The legions of “coders” bred by the tech bubble of 2000 are facing extinction; the roles of the software designer and Technical Architect are fuzzier than ever. Thinking inside of the language box makes a better coder but not a better software engineer.

Modern software design methodologies shatter that box. Domain Driven Design disconnects the developer from the technology and places domain rules before the intricacies of a language. Test Driven Development brings the Domain in the software realm and it does it by forcing to write the tests first, then write the actual code. Test-first forces you to think behavior and APIs first then perform the act of coding which is nothing more than implementing that behavior.
Eric Evans’s DDD: Strategic Design is an eye opener. And while you’re at it, check his other presentation about domain modeling.

So instead of “Thinking in Java”, think Domain and APIs first then act. In Java.