The tug-o-war of software development languages gets really confusing; it’s hard to decide what language would prevail and become the new standard in application development. Why is it important? Because we are application developers, and our relevance in the business landscape is linked to the tools we are skilled in operating.
I have heard Professor Martin Odersky say that Scala is the java of the future. Although I cannot vogue for such a promise, I can certainly say that Scala is the most compelling language I have encountered.
Scala has incorporated many ideas, new and old from the other existing languages. Scala functional and object oriented. It has cool stuff like traits (aka mixins) and Actors (erlang style threads) and advanced pattern matching. Most of all, Scala is expressive and esthetic. Clean and comprehensible code means easy and efficient maintenance, and that is important.
Scala runs over the JVM. Hence Scala can call upon java functionality and vice versa. Scala also has a .net support but that is not my scope at this time. According to professor Odersky, the overall performance is not hampered and the results are usually as fast as Java. Michael Galpin posted some figures about Scala performance on his blog here and Nick Wiedenbrueck compared Scala, Java and Groovy here.
Following are some interesting links I found for getting into Scala top down:
The phrase “everything should work as fast as possible” describes the wrong way for developing software. Software is a means to an aim. The aim is a functionality of a sort, just like a car or a house. When constructing a solution, one has to take performance in the context of the solution and not as an ideology.
Imagine how a house would look like if the drive way was paved four lanes wide just for the sake of performance.
The prioritization of performance is determined by the business requirements. A thorough analysis of the required throughput in each of the application flows reveals by itself the highways and the sideways.
Marking the road map in such a way is not premature optimization, but the proper use of the information that the architect has from day one. The final tuning can be done at the later stages when performance issues come up. However, developers need to know how wide the road they are paving should be.
It is so told, that there should come a time for every developer, when he be faced with the challenge of coding in the sky. A situation like this happens when a client is faced with a critical problem and needs an immediate solution. The solution provider decides to give it a go, sends out a repair man, for a fast, cowboy style solution, and cashes in the check.
When my turn came, I was handed the assignment along with the flight tickets and a brief rundown of the functionality I had to deliver. The functionality took about an hour for him to describe.
This kind of positive thinking often reminds me of the ‘Bazooka Joe’ bubblegum fortune, telling me that by the age of 21 I would probably land on the moon.
Keeping that same positive thinking in mind, I realized it would be a nice opportunity for setting my agile development skills to the test. I preach agility all the time. I preach it to my colleges and to my developers. I even preach it to my boss. There was no way I was about to turn ‘cowboy’ on all that.
The entire time frame for this task was less than a standard agile heart beat, but I stuck with the principles, and used them to guide me.
My first task was to deliver functionality. So I set to inquire whatever I could about the requirements. There was the way my boss envisioned it and there were some correspondence with the customer that preceded the request. I swept through the mail exchanges, to find out how the customer wanted it to work and how it ought to be fitted in the surrounding landscape of the other systems. I came out with a detailed feature list, reflecting the functionality requirements, an outline sketch of the interfaces and a high level cubistic design with a short list of would be obstacles (i.e. outstanding issues yet to be resolved).
Meeting the bare minimum to enable testability: I wrote a mock up interface invoker (two actually, that know how to talk to each other in a session like manner). Just like in the real world, my module was going to be ‘stuck’ right in between the two mockups, doing so I could have a convenient testing envelope where I can gradually grow my functionality.
I felt I was ready for some hard core coding.
Fortune: you will not get much sleep the next few nights.
I developed in short cycles. I used my short list of suspected picklesto define the steps for development. After coding a new solution that was suppose to address a particular issue, I ran the module against the testing facilities, with all the scenarios I had so far, and a new scenario that would test the solution. This got me through debugging and I made sure that I was not disrupting previously developed features (i.e. regression testing).
I know, I know, I was sprinting or whatever. In any case it kept me focused on my goals and constantly in check with working functionality.
I sprinted at the office, I sprinted at home, I sprinted at night, in the airport and on the airplane.
It so happened that by the time I got to the site, I was far from done, but I did have a prototype that was solid enough and being as it was, I had it installed on one of the development environment there.
I made use of the customer. The customer in this case was a respectable American corporate. I met there with the IT team that held everything together. Right at the beginning, they brought into my attention that they had four sets of environments. This was an important point to note since there were differences in application versions between them. The version differences meant that every time I got environmentally promoted, I had to adjust to the changes in protocol and behavior.
Fortune: an overnight success is the result of years of preparations
At this stage, I could have my testing cycles run up against real applications and not the mockup applications I prepared myself. The people from the IT team helped me learn about the extreme scenarios and together we were able to devise a meticulous testing plan. Together we defined the scope for load testing.
During the working hours, I ran tests on the various environments that were available and spent the nights at the hotel for code fixing and optimization. This was not an easy time for me. By the end of the first week we have conducted a few cycles of testing and amendment, and we were already deep into the load testing.
Fortune: the love you give is equal to the love you get
I was also able to cater for some extra requests for changes. These were minor modifications that had to do with logging and configuration options, but it made customer happy. The help I got from the customer staff I met there was absolutely essential in making the delivery and having the module go into production.
A month after I flew back, my module was set into production. Of course there were some more bugs identified and some new feature requests as well. But all in all, the customer was satisfied.
A giraffe, which I hold dear, once told me that agile application development is all about pace, straight forward thinking and relevance. I can’t help thinking that us humans, like to make things all so complicated, even when we intend them to be ‘agile’.
We adore rules and regulations, and a static algorithm is fantastic when your target is motionless. The nature of things is not as static and rigid and not having a timely response might lose us the patch. “Follow your own heart”, the giraffe would tell me, “it should be as good as anything else you might find, and you can always change the rules and adapt to the new situations as they present themselves”.
I couldn’t help noticing that there was a wide nose rhino, staring at us from the other side of a patch of coffee.
Grasslands and software projects usually exist within a particular window of opportunity. The grazing has to be finished before the grass disappears: the problem has to be identified, addressed and delivered before it becomes irrelevant. “It has to be done and over with before the dry season” the giraffe would say. Managing software projects with agility is all about keeping up with the changing seasons, and the other moving animals.
The rhino was eyeing us ferociously. He wasn’t going anywhere.
Sitting there, leaned against a baobab tree, I heard the ‘agile of three points’ coming from above, straight from the giraffe’s mouth.
Always deliver functionality
Develop in short manageable cycles
Make use of the customer
These three principles form the conduct and rhythm of agile development: Combined together, they insure the growth of the product in relevance, while maintaining a steady flow of fresh capabilities under close supervision and immediate acknowledgment of the customer for every step.
“Is it clear yet?” asked the giraffe. Here is some more:
Delivering functionality
Delivering functionality has to do with the continuous effort of implanting new business ideas and capabilities into the product by way of every software drop. Functionality delivered alongside other non functional changes.
The principal has two immediate benefits.
From the customer’s point of view, each code drop brings some fresh and new solutions he needs for his business. After all, new functionality is exactly what he paid for.
From the development standpoint, the proper prioritization for new functionality prevents the product from freezing while the development team works in full capacity in revising and rewriting already working code.
I’m not saying that code maintenance is irrelevant. Software releases should be a balanced concoction of improvements both in business relevance and in code quality.
Short development cycles
Development in ‘short bursts’ is an all too familiar concept to the Agile advocates. This is a principal that has to do with the pace of the development and of the software delivery.
Having short and manageable development cycles insures close proximity for each issue between the time it is developed and the time it is tested. Nothing is lost by time or forgetfulness.
Another byproduct is by having pending and immediate deadlines; it is easier to keep the developers in check and optimal production.
Of course I’m letting go of many other aspects, but I think this captures the essence.
Customer involvement
This principal has to do with relevance. Nobody knows the business better then the customer. Hence, customer’s involvement in the application development is an asset.
Sounds so simple, but it’s probably the most difficult to practice. To make this happen, the customer needs to have focal points for every issue that might rise in development, and define direct access to these key professionals.
Having customer representatives on board during progress and status meetings might sound to some as walking naked in Times Square, but the other side for this exhibitionism is the total involvement of the customer in progress and prioritization.
And while involvement means cooperation and clarity means trust, the chances of the project to eventually ‘go live’ is as high as is can get.
Maybe next time I’ll have a short chat with the rhino.
For me, software development is just a nice way of saying ‘bit moving’. A good friend of mine used to describe himself as a bit reorganizer. We rearrange invisible magnets, he would say, setting their tiny arrows of residual currents to point this way or that. We are a bunch of “bitniks” and we are all about data.
Application design and development has been my main source of income for the last decade or so, it struck me as odd that there were so few terms that describe so many kinds of data.
It occurred to me, that the Eskimos had their fourteen words for snow, and they say that the Bedouins have nine words to describe sand. I felt so alone. I felt a need for discovering my own flavors of data. It took me a while, but then in a single perfect moment of clarity, I had realized what lay before me.
The orchestration of the moment was this; in the middle of a design meeting, yelling and shouting all around, we were discussing optimization and performance and spirits were high. My thoughts went back to when I have learnt about application design. The fact was that when developing any business application, the first step to take is to determine the set of business flows that describe the scope and functionality of that application within the organizations it’s meant to serve.
Listing these business-flows by rank and cardinality is no bother at all. The simplest evaluation I could think of is according to frequency of use and the sheer number of users that would eventually use the flow.
I thought that the categorization of the data body by the same yardstick could provide me with the flavors of data I was looking for.
