Business people really trust in us!

When you are writing enterprise applications, on most cases you are automating information flow, enforcing business rules and managing persistence. No matter what programming language are you using, you need to understand the business. In this post I wanna share some questions that are in my mind...

1. What is the most difficult stuff about making enterprise applications?
In the applications I'm working on, persistence or UI related stuff is not difficult. The hardest thing is to understand business needs, understand their rules and writing them in a way that a computer can understand. We state our understandings using use cases and other requirements documents, then our business people leave us alone, hoping that we really understood them.

2. How much trust do business people put in our teams?
Wow, I think they trust us a lot! We wrote the use cases, they approved them and after several months without seeing the actual software working, we release the software they'll use. Their jobs depend on us doing the right thing.

3. How do we respond to that trust?
Many times, we as software developers aren't conscious on the critical nature of our software, but we want to make a good product. At my job, we apply some agile practices, but our process relies on a big initial requirements phase and a final testing phase. We use TDD, Continuous Integration, we do code inspections and try to go on with the schedule. Then testers try to understand what the use cases state the software should do and use it in our testing servers. An business people? They are trusting in that the product that they have not seen yet is what they expect. Wow, they trust us so much! BUT maybe, the software works great but isn't what they are expecting. Maybe we automated some calculus but they haven't had a chance to use it with real sample data... We software developers do the best but I think we need one more thing.

4. How do we know that they are confident that their business rules are enforced by the software?
We need to be better in our communication. Let's speak more with the business, let us not rely only in formulas, let's ask the business people for real data examples. Last week I found put that they use Excel a lot for explaining their intents. They can give us many tables of example data. Real data that could assert that our software does what they want.

And that's the goal right? Great software solves real needs. it doesn't matter If software is delivered on time, on budget and according to requirements documents, but isn't what the real users need. Quality is perceived in working software doing the right stuff.

So, as a conclusion, why don't you give users the possibility to give you real examples, use them throughout your development and try everyday to improve your communication. Collaborate more, we are on the same team.

Weekly readlist - Jan 18, 2008

Hi! I'll try to keep a record of some articles I read and share them here. Remember that the sidebar is updated with the most interesting posts I read on of the blogs I follow.

Agile Planning
Our Professional Responsibility

Acceptance Testing
Introduction to FIT
Introduction to Fit and Fitnesse Part I (podcast)
Introduction to Fit and Fitnesse Part II (podcast)
Patterns and Anti-Patterns: Acceptance Testing with FitNesse

Requirements Management
Agile Principle #4: Agile requirements are barely sufficient!

Project management
A Practical Guide to Seven Agile Methodologies

Code generation
NVelocity

NVelocity is a port of the excellent Apache Jakarta Velocity project. It is a very simple, easy to learn and extensible template engine.

The Ferrary 599 and software

I was watching in the Discovery Channel a show about the Ferrari 599 and how they deliver the highest quality in that awesome machine. They seem so proud of their product! Every interviewed person was sure that his participation in the production process was important for the end product's quality.

I just wanna blog about two more things I realized:

- Each step in the Ferrari production process assessed it's quality. They knew which acceptance tests would allow the part in production (motor, leather parts, etc...) to go on in the process and be a part of a $240.000 car. Everything was done so they'd meet the expected quality... "Buyers are paying for perfection" they say. So, they minimized surprises, since they knew the expectations from the beginning.

- Any defect in the manufacturing process meant that piece would be rejected. If the chasis didn't meet the expectations, it was returned to the melting machine and they started clean with a new chasis. So, each process was sure that it was receiving quality parts.

The result?



Maybe we can learn something for our software development process!

1. Everything in the 599 manufacturing was done with the final product in mind. There was no waste. The process was well designed and executed with excellence. Do we do something during the process that doesn't add value to the final product? I'm not talking about not making any documentation. I'm sure everything in the 599 is well documented. I'm talking about being sure that every artifact, model and code adds value to "our Ferrari".

2. Validation: How do we define quality in our product? Is the user involved in that definition? Which are the acceptance tests that certify that your code does what the user expected? This practice is the one that is catching my attention lately. If we use some testing framework in collaboration with our customer to define the user's expectations, we'll be closer to define what quiality is for her. And, we are done when we find out that all of our acceptance tests are green.

Well, these are my thoughts; I think many people is doing great things with TDD and other agile practices... why don't we try them out and get the best of them?

New things! Check DbFit...

I was commenting with a partner today about how you can keep track of new technologies and practices. Software development is so pragmatic that an idea can be cataloged as "crazy" one day and the "silver bullet" the next... And the question is ¿what do you do as a professional software developer to be updated and share your new ideas with the community?

That's one reason why blogs are so great. They are free, easy to share, to update and you can keep up with their new contents with great readers (like Google Reader). Wow, when you are keeping track of 18 blogs and 9 podcasts there is something new every day, how cool is that?

If you want to start chewing a new idea right now, I recommend you the article Test-first development with FitNesse. I think maybe this could be the next big thing in automated testing.

Also, keep track of Test-driven database development with DbFit. I was chatting with the creator (Gojko Advic) and he has some great ideas he's applying on his projects. DbFit uses Fitnesse for creating your database tests in a wiki-style, with a very easy syntax and it manages the transactions so you don't leave corrupt data on your database. And Great news - SQLServer 2000 is now supported in DbFit for all of us who aren't still in 2005.

And of course, you can integrate Fitnesse and DbFit results into CruiseControl.Net, explained here.

So, there you have some new ideas, IMO with great potential to improve our software. Why don't you take some minutes to read that links and keep tracks of some related blogs? Check my blogs and podcasts on the sidebar. Stay fit!

What do you love about making software?

I love to do software because it can make people's life better, solving real needs. When I make something and someone uses it gladly, that's priceless to me. That's why I want to make great software. Don't you?

So, our goal should always be to satisfy real needs. I think that's why endless projects make software developers get so tired, dropping their productivity and motivation to the floor. They find themselves coding and coding without ever seeing any user using they product! No feedback, no gratification, no improvement. How frustrating! Is there a way in which we can add real value to our users fast and frequently, even when working in large systems?

Agile software development is many times referred as a lazy process, without enough documentation and with no upfront design and architecture. How untrue is that. Since I started reading The Art of Agile Development, I started to realize how disciplined and professional your team is in an agile process (XP in the book). Besides that, the focus on adding value to the business frequently makes your users more involved on your project and satisfied by your software.

I found a little (5 min) but clear video that answers the question: Why does Agile Software Development pay?. I really recommend it to you as a brief introduction to agile and how it adds value to our users.