Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Saturday, November 27, 2010

Proof of Concept for the BLDD Tool - Part VI

We have released a compilation of the posts with some more explanations on our proposal for the Business Language Driven Development (BLDD) draft, the technical report can be found here.

There is a lot of work to do on top of BLDD, such as:
- Defining in more detail the use of a companion textual Domain Specific Language (DSL). Probably with support of a Rule Engine.
- Implement an usable tool, we are investigating an extension of Drools for this purpose. Drools seems to be a good choice because it is BPMN compatible, implements a Rule Engine, and an Eclipse plugin. And, of course, it is open source.
- Implement BLDD on top of an ERP, our choice is ERP5, for the reasons listed on the first post of this series. This case study should show the applicability of the proposal.

You can find more "future work" in the report. We are open to collaboration and discussion.

Wednesday, November 24, 2010

Assorted Thoughts on Agilism X Traditionalism - Part III

This blog focuses on Free/Open Source (FOSS) and Agile/Lean (AL) for Enterprise Information Systems (EIS). NSI has been using Free/Open Source since its creation, in 2002 (I use since 1998), however, AL is relatively new to us. I think it is interesting to tell how we "realized" AL.

Our Turning Point

In a broader sense, we started using automated testing in 2005, when we were developing a system for vibration analysis in LabView, which uses G, a visual language for Virtual Instrumentation. For us to test it, we had to simulate working gas turbines, which means to generate matrices with thousands of lines and dozens of columns, representing the vibration signals produced by dozens of sensors. In fact, we had to develop a complete simulation module that excited the analysis algorithms. Curiously, parts of this module were created before the algorithms, because we needed to understand better the behavior of a real equipment, in a kind of "proto" test-first way. Also, we filled vectors and matrices with trustful results obtained from laboratory's hardware and software, and automatically compared with our results, to check our algorithms' accuracy.

In the realm of Enterprise Information Systems, our use of automated testing was initiated only in 2007, when we started two important Enterprise Content Management (ECM) projects in parallel. We started to automate the "black box" tests - because we had no patience to simulate dozens of time the same users actions - and load tests, for obvious reasons. However, our unit tests weren't disciplined and sometimes were hampered by the platform we used. Obviously, the acceptance tests started to find wrong behavior in the software, given the lack of complete unit testing. By that time (with results published in 2007/2008), and in parallel, we developed a hybrid development process for the ERP5 system that used MDD (including a nice set of supportive tools) with automated testing.

The year of 2008 represented our turning point, because of three factors:
(i) We realized that our MDD-based process for ERP5 was sound, however, our industrial partners needed something leaner, and MDD didn't made much sense when developing on top of a highly reusable framework. Moreover, refactoring made modeling a waste in general. We realized in practice that a good design can be done on top of code, instead of models.

(ii) I managed to bring to the team an associate researcher who was (is) a very competent developer, and was (and still is) experiencing very good results by using Agile Methods. He made me remember of my Master Thesis (1997), which proposed a hybrid push-pull production planning and control method: instead of using complicated production programming algorithms, which needed very accurate (and usually inexistent) informations, Kanbans were used to smooth the production flow.

(iii) I read the book Ghost Force - The Secret History of SAS, written by Ken Connor, and realized that trying to use conventional methods for managing unconventional projects and teams was stupid. After exposing my impressions on some team coordination techniques narrated by the book, we immediately adopted two principles*: a) one man, one vote (the Chinese Parliament) and b) the one that holds more knowledge in the specific mission, leads it, doesn't matter his/her rank. Of course, we already knew that the most valuable asset of any team is its human resources.

*strangely my team didn't accept things like parashooting training, as well as other really interesting techniques presented in the book ;-)

So, I can say that we woke up for agile techniques as a whole in 2007/2008. In 2008 we started to use a Scrumban process, a mixture of Scrum for planning with kanbans for programming the production. Things weren't enforced, we realized that disciplined automated testing and Scrumban was superior for our environment, and that's it. When I say we, I am referring to everyone, from vocational to master students and researchers (one man, one vote, doesn't matter the rank...). In 2009 we started to use BDD, actually, we developed a tool stack for BDD in Python to serve to our projects.

In other words, although we are a small organization (circa 30 developers in different projects, divided into development cells, plus some 10 aggregated people), we came from a traditional way of thinking (but we never were bureaucrats) that in fact never worked well for us. In other words, we use AL because we realized in practice that it is better for us, not because it is fashionable. An interesting point is that our last paper on MDD + Automated Testing was cited by a very well known Software Engineering researcher as one of the references for modeling EIS.

We studied and tested the techniques by ourselves, using the Chinese Parliament and The Best in the Mission is The Leader principles to put them in practice. We did right and wrong things, adapted methods, mixed techniques, created tools for BDD, for improving programming productivity, for automated testing, for kanban control, and many others, only to cite a few, and we also used other people's tools. Basically, we discussed a lot. In other words, instead of following some manual, or standard, or course, or pursuing some certification, we created project management knowledge! A good result of this is that all five students that left our research group this year are working for innovative organizations, with salaries higher than the average. Moreover, they got their positions in highly competitive markets, including Europe. They were all hired in the same way: staying some days in the organizations, programming with the teams and taking part of meetings.

An intimate commentary: now I feel totally comfortable to teach project management and tell my daily experiences. Before that I had to teach techniques that didn't work for us, but I had to insist on teaching them because the books said that they worked - while feeling as an incompetent project manager. Now I can see that it doesn't work because this type of process cannot deal well with uncertainty in general (maybe really I am not a good project manager, however, now thing work well for us anyway).

A last commentary: although we are part of a teaching & research organization, we've been developing serious projects with companies and government agencies for years. When I say serious, I mean projects with deadlines, fixed budgets, lots of users, need of continuous support and evolution, and that are expected to aggregate value to the users' organizations. Every single software we developed since 2002 is/was either used internally - in our development process - or by our industrial and government partners. Moreover, since we develop free software, our products are also used by other people and organizations besides our formal partners.

Sunday, November 14, 2010

Assorted Thoughts on Agilism X Traditionalism - Part II

Back to Basics

Management has three basic functions: Planning, Execution, and Control. We can summarize the basic differences between traditional methods and agilism/lean in a table:

-Based on effort metrics to plan the whole project

-Change is a “risk”
-Design = models
-Try to automate programming
-Centralized decision-making
-Quality a posteriori, by annotation, and responsibility of a specific team
-Try to be static (follow the original plan)
-Based on collective evaluation and on measuring the current development velocity
-Plan for the next period
-Embrace changes
-Design = code
-Automate repetitive tasks
-Decentralized decision-making
-Quality a priori, automated, responsibility of producers
-Try to be dynamic (follow the demand)

In my opinion, the difference is basically one: Agile and Lean seeks to be dynamic, Traditional seeks to be static.

Friday, November 12, 2010

Assorted Thoughts on Agilism X Traditionalism - Part I

Some days ago I took part on a debate on Agilism X Traditionalism for Software Quality Assurance. Firstly I accepted to take part of it after its organizers changed the original name: "Agilism X Software Quality", as if Agilism were against Quality! Yes, there's still people that thinks that Agilism means non-organized, low-quality development, simply because agilists don't like to take a lot of notes or of using a lot of models. It reminds me of the early days of Free/Open Source, when most people that were against it never took part of a FOSS project, or even "touched" any open source software.

I read somewhere that Agilism (like Lean Thinking) means a change in the mindset. That's why, IMHO, that many people cannot understand how Agilism works. The bureaucratic mindset cannot understand how a technique that doesn't use a lot of annotations, long meetings, change management boards, hierarchical planning etc can work.

That's the same mindset found on USA's automobile industry in the 60's and 70's that was defeated by Japanese car builders. USA industry couldn't understand how a plant controlled by paper cards could work better than the enormous management structure they had, which was matured on top of decades of experience in building car - after all, they had Ford!

But the Japanese did.

And they still do, in spite of the current Toyota's quality crisis, its followers still reign in the automobilistic industry. I see people from the traditional methods in software industry with the same arguments:

-Agile doesn't scale = JIT doesn't scale.
-You need to plan in detail beforehand* = JIT has no planning tools.
-You need to take notes of everything you do otherwise you will loose control = for JIT taking notes is considered waste most of times, do things in a way you don't need to take notes.
-How can quality be controlled by developers, instead of a separate group = how can workers control quality, instead of Quality Control Department.

*(although detailed and accurate plans for software development are unfeasible in real word)

The truth is that things like automated testing, continuous integration, refactoring, and all other modern development techniques were born in the Agile cradle. These are Product related tools. Traditionalists still play with Process related tools, repeating the "if the process is good the product will be good" mantra. Yes, we need a good process, sure, however, you must try to avoid become mesmerized by the beauty of complex project management processes. Instead of putting a lot of people to take notes of a lot of stuff and correct your planning all the time, try to avoid problems, instead of trying to correct them. The focus must be on the product, therefore, product related tools will bring much value to your production chain than process related tools.

I believe that the only really scientific way of producing software is through Formal Methods (FM), because it represents the use of Mathematical principles for building software. If someone can use the term Software Engineering, are the "FM guys". The problem with FM is that they are still quite hard to understand and apply, and there are only a few people really capable of using them to produce software. While FM doesn't produce things like the tables that engineers use to simplify their calculations, FM won't reach the mainstream. FM methods are still dependent on developing "ad-hoc" mathematical models, and the ordinary developer doesn't have the skills for that - like the ordinary engineer, who doesn't develop mathematical models, instead, make use of them. Maybe when FM become usable by the ordinary developer we will be able to (really) do Software Engineering.

Therefore, we must, at least, be the closest to FM we can. Now, tell me what's more formal:
-Running code.
-Drawing models and using manual annotations to connect them to code*?

*(code generation is mostly limited to skeletons, someone will write algorithms anyway, therefore you will need to connect things by hand in the end).

You must agree with me that running code is much more formal than models and annotations, simply because the first is the thing of what software is done. So, please don't tell me that MDD is "more scientific than Agile because has the same principles of the other Engineering disciplines"... Running code means a functional machine, and that's the basic principle of... Engineering!

ps.: Like in the (hard) industry, Agilism automates repetitive tasks, such as testing and building, and this automation provides safer software verification. The other "end", Validation, is provided by BDD.

Wednesday, November 10, 2010

Effort Metrics Sophisma - Part IV

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.

So, what's the point?
The point is that the starting point is wrong! When people from the software development area sought for references in planning in the industry they thought it was obvious to check the techniques used by the custom production industry - where each product represents a different production project, and therefore, design is done product by product - not from the repetitive production industry, after all, software development is custom production, instead of reproduction of the same design in large quantities.

However, the reality is not that simple. While custom production runs under a low uncertainty environment (given that the product design was done beforehand), repetitive production usually runs under uncertainty - demand uncertainty.

Demand uncertainty is what happens to software. I not saying uncertainty in quantity, but uncertainty in building effort. Therefore, although we are talking here about a custom product, the techniques that apply to its production planning activities are the ones related to repetitive production.

In my opinion, those related to Lean Thinking... I am going to talk about this in future posts, now let's go to our third and last logical chaining.

Third Logical Chaining
From the second chaining:
Knowledge based production AND intangible good → there is no physical metrics
Non physical metrics → inaccurate estimates
We have:
Inaccurate estimates  → high uncertainty in the production process
Custom Production → low uncertainty in the production process is expected
Although software development is custom production, it is not reasonable to use industry's custom production planning methods because they expect low uncertainty in the production process, but what we have is high uncertainty !!!

Now that I have shown, with some formality, that the current effort metrics don't work for software, I feel more comfortable to go forward and explain how to use Agile and Lean Thinking methods for software development planning.

Friday, November 5, 2010

Effort Metrics Sophisma - Part III

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.

The (Tough) Software Reality
Unfortunately, software is an intangible good, produced by knowledge workers. An intangible product means that it is not possible to measure its physical features, such as weight or diameter. Production based on knowledge is also hard to measure, because it isn't repetitive: there isn't something like the industry's "medium operation leadtime". Moreover, software development is highly dependent of people*, with all their specificities, problems, way of thinking etc.

(*If MDD were really able to drastically reduce the need for programming, organizations would no longer be hiring lots of programmers ...)

In other words, uncertainty in software development comes from:
- Non-repetitive and creativity-based work.
- Constant changes in technology.
- Some tasks considered as simple behave as complex.
- Frequent changes in requirements.
- Necessity to learn about the domain area during the development
(the above arguments are also valid for defending iterative & incremental cycles...)

Second Logical Chaining
Software → intangible good, non-physical
Software → knowledge based production, knowledge is a non-physical resource
Knowledge based production AND intangible good → there is no physical metrics (by definition)
Non physical metrics → inaccurate estimates
From the first chaining:
Detailed planning needs → detailed estimates
Software → inaccurate estimates
Inaccurate estimates → non detailed estimates
Non detailed estimates → Non detailed planning

In other words, it is not feasible to produce detailed planning for software, even when using waterfall cycles !!!!!

The central point for reaching this sad conclusion is
Non physical metrics → inaccurate estimates

I leave this hook here so that people can try to dismantle our arguments: if you prove that you can have accurate estimates without having physical metrics, the argument here is broken.

More Conclusions
Detailed planning works in the hard industry, however some people try to transplant it to the software development industry in carelessly ways. Many organizations insist in this broken model, bringing high costs to the control and (re)planning functions, and in the end the goal is not to deliver a good quality product ontime anymore, but to create a false notion of control and of showing that managers are able of "thinking ahead" (although this "ahead" is unknown in the real word...).

For business people, not being able to create a detailed plan for months ahead is something like signing up a "proof of incompetency", many prefer to create plans that need strict control and even so, their baselines change all the time. At this point, the tail starts to wag the dog...

Tuesday, November 2, 2010

Effort Metrics Sophisma - Part II

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.


I will interrupt a bit this series because I have just bumped into an "old" article on software metrics, about which I would like to comment briefly: Jones, C. Software Metrics: Good, Bad and Missing, Computer, vol. 27, no. 9, pp. 98-100, Sept. 1994.
Its abstract says
The software industry is an embarrassment when it comes to measurement and metrics. Many software managers and practitioners, including tenured academics in software engineering and computer science, seem to know little or nothing about these topics. Many of the measurements found in the software literature are not used with enough precision to replicate the author's findings-a canon of scientific writing in other fields. Several of the most widely used software metrics have been proved unworkable, yet they continue to show up in books, encyclopedias, and refereed journals.

Although it was published 16 years ago, I think the problems listed on this paper are still valid, and the paragraph above manifests my opinion on the use of metrics for planning in software: they only work under certain conditions and may have worked for a given sample of projects, but may not work for my project. In my humble opinion, the current metrics don't present a sufficient level of determinism so that we can  use them seriously for planning.

As I said in this series' first post, if I produce a brick here in Brazil, it will present the same size and weight in China, for instance. If I use the correct Engineering units and calculations, someone will reproduce "my experiment" of using these bricks anywhere in the Globe*. But the same doesn't occur with software requirements and thus with source code. I can send the same requirements for different people and they will implement them using different languages, paradigms, algorithms...

*(before someone say that bricks done in Brazil can present different plastic behavior in other regions of the Globe, I say that Materials Science has already developed methods to deal with this, while Software "Engineering" is still far away from doing the same for software.)

It is amazing how people use those constants found in some metrics (such as the one found in Use Case Points, which still gives 47,000 hits in Google...) without thinking that they maybe be not applicable to their specific project!

Therefore, if "So long as these invalid metrics are used carelessly, there can be no true software engineering, only a kind of amateurish craft that uses rough approximations instead of precise measurement.", I prefer to use experience and short iterations for planning.

ps. 1: the cited paper defends the use of Function Points, which I think is not applicable to Iterative & Incremental cycles.

ps. 2: I will repost a previous remark on UCP: Tell me how can you use it in an (really) Iterative & Incremental project (remember that real I&I cycles only details Use Cases when needed, so how are you going to count the number of steps for every use case and then get a "precise" effort estimation?). In spite of this, many teachers still teach UCP and I&I cycles in the same package...