Software Development At Heart

Software Craftsmanship is an alternative way of thinking about the activity of writing computer software and skill acquisition mechanisms. It is a growing movement amongst software developers dissatisfied by the mainstream software industry’s focus on the skill-level of the median programmer.

In December of 2008, a summit was held in Chicago that resulted in the drafting of the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Although we are using code generation more and more, shifting some responsibilities away from the average developer, we still need to keep crap code at bay. When we upgrade to model-driven development, we switch to the trade of keeping crap models at bay. A Software Craftmanship orientation is here to stay and we should embrace it.

In-house code generators help implement a Software Craftsmanship initiative by enforcing the use of correct and tried-and-tested designs and patterns.

Read more about Software Craftsmanship (books @ Amazon):

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
Clean Code: A Handbook of Agile Software Craftsmanship
Software Craftsmanship: The New Imperative
The Craftsman

I’ve just signed the manifesto. Did you?

Whatever the next software development breakthrough will be, it must be supported by strong asset reuse techniques.

Like any other engineering discipline, software engineering can gain a lot from a solid discipline of reuse. But unlike other engineering disciplines, software asset reuse does not come naturally in software engineering. When it does, it never comes without costs and risks.

Possible reusable asset categories:
- Requirements / Specifications
- Documentation
- Designs
- Architectures
- Source Code
- Test Data
- Executable Code

Software asset reuse starts by being a cultural thing. Managerial aspects play a critical role in it. Software asset reuse cannot happen without strong commitment from the managerial structure of the development organization.

Reuse Libraries and DSM (Domain-Specific Modeling)

We can consider two types of reuse libraries: Horizontal and Vertical.

An horizontal library augments the expressive power of the language without commiting to a specific application domain. It has the advantage of being useful across several projects, but it is limited to around 20% of the application’s total code.

A vertical library contains domain-specific components, and can reduce the amount of coding we need to produce by up to 65%. The drawback is that it can only be used within a single application domain, and hence potentially few projects

If we map these two types of libraries to the DSM paradign, we can say that an horizontal library lies on the solution domain, and a vertical library lies on the problem domain.

I’m sure it happens to you. As much as you try to guess in advance all the problems you may find during development, you’ll end up fighting some problem for hours. You think it over and over again. And again. A solution is nowhere to be found.

It happened to me several (too many) times. Most of the time, after much fight, I end up reaching a solution. But on a few occasions, something startling happened: After quitting, usually because time ran out that day, I return the other day and find a solution in five minutes or less! And a simple one. “So easy!… Why didn’t I think of that yesterday????”

I start to wonder how much time I wasted by not quitting to fight the problem.

So from now on I decided to have a new approach to problem-solving: If it starts to take too long to solve, I move on to something else, and leave it for tomorrow or the other day. And I advise you to do the same. You’ll end up saving time.

The reason for this quite surprising effect lies on the fact that when we have a problem, we set a series of reasoning “paths” that, unfortunately, lead us to the same “solution candidates” over and over again. At a certain point, we cannot deviate from those paths anymore. We become stuck, or run in circles.

If we leave the problem behind for some time, we have the chance to rebuild those reasoning paths again, hopefully in new directions. But don’t leave it for too long. That’s because there is always important information you must retain to be able to solve the problem. The longer you leave it, the harder it gets to get started again.

Knowing when to quit helps you save time solving problems. Think about it.

Still typing code by hand, in a mess of source files, function names and repetition?… Upgrade yourself! Move to the next level with models and code generation. Ok, this not a subject for the beginner, but those that are/feel proficient in their current setup (.Net, Java, RoR, PHP) should not learn a new (yet another) language. Don’t move your competences to the side. Move them up!

Code Generation 2009 is “the” event for Model-Driven Development and Code Generation. Learn more about it here. If you’re interested in these subjects, you must definitively be attending.

Following a suggestion left on this blog by CG2009′s boss, Mark Dalgarno, I’ve submitted a proposal to be hosting a session in the event. In such session I would be speaking about the results on my research over the last nine years: Atom-Based Software Engineering (ABSE), a form of Model-Driven Software Development that is understandable by mere (developer) mortals. The theory is now solid enough, the proof-of-concept is seeing the light of day, and the timing is right.

Let’s see how the CG2009 comitee judges my proposal…

Today I’ll talk about ALM, Application Life-Cycle Management, another acronym that is omni-present in our development practices but is seldomly noticed.

The hallmark of industry leaders today is flexibility and agility. Organizational re-structuring is an on-going process. Geographical boundaries are no longer a barrier to collaborative development initiatives, and virtual teams are found everywhere. Software development practices must keep up.

In the traditional model, the application’s life begins when it’s envisioned by a stakeholder. Next, it’s designed by an architect and coded and tested by developers. Once development is complete, the software is run through QA by test teams and deployed by administrators. After deployment, it’s maintained by developers and administrators. Periodically, new versions are designed, coded, tested and deployed. Some day, far in the future, the application is decommissioned.

Every software house has implemented an application life cycle in its own way. Every organization also has its specific requirements for ALM tools. More than just development tools, today’s ALM solutions go beyond architecture, development and test. They encompass everything from project management, build management, source configuration management, metrics, reporting, process compliance, collaboration and governance.

In a modern ALM implementation, everyone involved in software development can actively contribute to the entire application life cycle, not just to their portion of it. Managers can see the entire life cycle of their projects, and understand how their resources are being used, and where workflow is not being as efficient as it should be.

A very important benefit of modern ALM solutions is that they can make software less expensive to build, in real terms, by accelerating portions of the life cycle, enhancing quality standards, providing meaningful metrics and fostering code reuse.

ALM is a process that naturally fits within AtomWeaver, being developed at Isomeris, my microISV. The true power of model-driven code generation will be realized when it can be properly supported, managed and applied.