Why small software companies are more dynamic

I’ve read the post from Eric Lippert on Fabulous Adventures In Coding , describing what’s the “real work” behind 5 minute of development at Microsoft:

One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.

One program manager to write the specification.

One localization expert to review the specification for localizability issues.

One usability expert to review the specification for accessibility and usability issues.

At least one dev, tester and PM to brainstorm security vulnerabilities.

One PM to add the security model to the specification.

One tester to write the test plan.

One test lead to update the test schedule.

One tester to write the test cases and add them to the nightly automation.

Three or four testers to participate in an ad hoc bug bash.

One technical writer to write the documentation.

One technical reviewer to proofread the documentation.

One copy editor to proofread the documentation.

One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.

Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.

A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

And I garrantee this is not a joke…this is true. During my short carrier in software development, I’ve seen all size of software companies: from 6 to more than 7000. I’ve seen this only in large companies, so what startup (I guess we can also apply this to Open Source) companies are doing to handle this? They simply dont care and don’t do it.

Jeff Atwood comment also on this in his post Is Eeyore Designing your software saying that startup and Open Source do not have all this development process.

What is the rational for such heavy process? I guess at least 2 reasons: type of customer and sofware development vision.

Some of the large companies are targeting large customer (Fortune 500 for example) to sign for large deals. These customers are world wide companies, so the localization is key to close a deal. The documentation is also important. They also emphasis standards in their selection criteria as 508 compliance for US governement. Thay also have technical schemas as for example allowed operating systems or supported application servers.

The software development vision of large software companies is also an industrial view: be predictible through control and strong processes. It’s very common to hear people saying:

• You can’t manage what you can’t measure.
• You can manage quality into a software product.
• Software needs more methodologies.

These are part of the fallacies highlighted by Jeff Atwood (yes again) in his impressive post on Revisiting The Facts and Fallacies of Software Engineering.

I had a boss who was questioning : “Why building software is no as simple as making a car?”. He was refering to the ability to deliver a product on time with good quality…which is very rare in software delivery. First, making a car is not so easy, but I agree from an external point of view, it seams more predictable et cars more robust than softwares. The main reason is that software development echosystem is evolving a lot and quicker than car making technologies. The tools are always changing, every month some new technologies appears, even languages, methodologies also are evolving a lot. To gain predictibility, large software company are enforcing processes that decrease drastically productivity.

XML has been overused

XML had its buzz periode 8 years ago, everybody rush on it to store information. It followed the hype curve, some technologies as RDBMS based on XML simply crashed, other as DTD has been replaced and finaly had been adopted by all the community.

Then it became the obvious solution to many problematics…maybe too much. I talked about this in a previous post on Why not coding in XML? (sorry about this one which in french). Coding in XML is simply a bad idea and BPEL is a good example of that overuse. I share the opinion of Jonas Fagundes when he sais in his post The misunderstood Maven:

“The weakest point in ant IMHO is to use xml to define the targets, for me xml is for data, I never liked programming in xml”

We start to see initiatives that try to readjust this.

Ant is a very good example where I think XML is not accurate. Ant is a tool that replace our old make files. Its aim is to execute commands to build a software (and much more, as deploymeny, test…etc). It is a knid of language, you have commands (functions), properties (variables), and conditional for commands (a kinf of “if” statement). Even if writting ant xml file is quit simple, for complex project with multiple tiers of different kind, and tests…this start to become a mess and you feel the need for best-practices.

I think the xml is not the right support to write code, and some open source projects goes into that direction as gant, Rake and Bake for example…this is the arrival of coding over XML…hence DSL.

GRails 1.0.1 installation fails

I’m having at look a GRails 1.0.1. I get a little problem after setup and here is a little trick to help you if you encounter the same kind of problem.

So I installed version 1.0.1 that you can download here. I’ve set up the environment variables and launched “grails” on the command line.

At that point I get some weird message as “Xxxx was unexpected at this time”. This was due to my JAVA_OPTS. To find the problem, just setup the DEBUG environment variable to anything you want.

This way you will see the content of the batch command executed and will be able to find the root cause of your problem.

GRails 1.0 is out

You can have a look at it …but use firefox as the web site has some display problems on IE (or maybe this is due to my IE configuration).

Finaly the famous Rails framework enter in java world, that should provide excellent reasons to no more see this RubyOnRails video:

[youtube:http://www.youtube.com/watch?v=PQbuyKUaKFo]

BumpTop 3D Desktop Prototype

A new desktop usability experience that worth to have a look at.  

 

 

 

PaaS is SF…

…SF as Software Factory, I mean a full featured development infrastructure. This became obvious to me when I read the post of Ayende on his vision of entreprise platform.

Ayende had the idea to base the system on code versioning system. This is definitely a great idea that I share, but I think this should go beyond: a complete software delivery infrastructure. The customer (software providers in fact) should be able to build, test and deploy applications….services for others users.

The great idea to relly on a source control system will solve the problem as versioning of the applications (for a part of it) and when you have multiple developpers working on an application or service. But this does not fullfil all the requirement for a PaaS, what about tests & validation, deployment (especially for multi-tenancy), delivery, maintenance…etc.

Finally, the requirement is to provide to some users a full featured development and delivery environment. The excellent post on the Lack of good Paas platform is highlighting very well all these requirements: customization and configurability, versioning and multitenancy, security, scallability.

I would add a requirement on robustness: as soon as multiple users can deliver software on top of platform shared by all…there is a high risk to have the system out of control. Ensuring a high level of service is fundamental, so the system should be really robust. The challenge is to let the system open (the sw providers are building software – so very high level of freedom) and “a live”, but this will be the topic of another post.

Illusion Of Control

Jimmy Bogard have written a very interesting post on Flexibility and control.

He is writting: “The manager had likely fallen under the illusion of rigid control leading to more predictable success.”

His image with arrow and guided missile is terribly true and helps a lot to understand agile concept. Has I’ve already written in a post on Agile Practices With Waterfall Management, management that does not embrasse really agility (maybe due to some misunderstanding), this can produce very weird effect.

Agile Practices With Waterfall Management

What about Program and Development Management that are using a waterfall approach with agile development team? By waterfall approach for management I’m talking about management decision not to start the development before requirements are defined, planification and release date setup. It’s not unusual to see also a stabilization phase defined as for example the last couple of iteration.

This is mainly due to:

• Product Management team is not ready at all for the first iteration,
• Infrastructure changes not identified before the first iteration,
• Product Management wants to have a full plan on the future release before starting, to prepare pre-announcement.

The final result of this approach is that the development team is not working at all…because it’s simply forbidden. The market driven approach has been well understood by Product Management and they are blocking any kind of development before they have decided what features have to be implemented.

Joaquim Rendeiro talk about co-existence of waterfall (especially for management) and agile methodology in his post on Agile or Waterfall?. Yes, they can exist but may have the consequences I’ve talked about.

IMHO, this occurs inside teams that are transitioning to agility and are not mature enough on this agile approach. As agility provide a huge responsibility and control capability to the product management, they used this extra-strength keeping in mind the waterfall approach targeting dates and content of the releases.

The development management should be the driver to accelerate the transition to a real agile approach. For example by rejecting all big kick-off meetings to start a release, and encourage a better preparation of each iteration. The development team managers should also avoid any technical discussion include an product owner and take the responsibility to make the technical choices. Often, the technical choices are delegated to product owner. Yes this is strange, but haven’t you any discussion with a product owner like: we can implement the story this way and it will cost 13 points or a different way and it will cost 21 points but this last one is less good for reasons A and B. Let guess the answer…do the shortest path. Even if this is usually the good answer from a technical perspective (I’m supporting the principle of simple design which is often shorter to implement), there is not reason to delegate this decision to product owner.

Agile approach requires a clear definition and separation of responsibility for every shareholder.

Agility For Large R&D Team

Getting agile is probably the only (or best) way for large R&D organization in a software company to setup their workforce in front of their need. They usually are working over multiple products (legacy or not), and are market driven. In small software companies, the product management marketing function is endorsed by R&D management and they work usually on a small number of projects which are at least tightly integrated, which means R&D team is focusing on only 1 common goal.

Start-up have focused/sharp vision, excellent creativity. Large company are relying on strong market analysis and capacity to move on…most of the time as soon as a startup has demonstrated new markets.  Vijay Challa talk about this in his post on Agility World 2.0.So, they have to invest (put development resources) on the products depending on the market trends, profits from each product,…etc. That’s why its important to be able to switch developers from a product to another to be reactive.

Some agile principles helps for this:

• iterations and time boxed releases to have reactivity when some resources are removed from a project,
• sharing knowledge instead of specialization to be allow reallocation,
• pair programming to reduce learning curve when new developers are working on a new project.

I tend to think that agility is maybe not always that relevant for small company, but its certainly a must have for large software company to be reactive.

Critical Code Mass

Agile methodology are based on the capacity to make the code evolving. Extrem Programing have some principles around that as simple design and continuous refactoring for example. Notice, that the aim is not to anticipate future evolution.

Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability.

All this is about complexity of code, but this does not means thousands or millions lines of code. Of course, having a very tricky algorithm written with a too large code base will create difficulties when an update will have to be done: a new developer will need time to explore this code before doing the change (maybe even do some prototypes). Even the author himself of the code maybe request additional time to test the change before checking in.

The Critical Code Mass can also be achieved on a very small code base, for example, when the algorithm have kind of magic: few lines of code, but it is not obvious how it work and even why it is working. Implementing a change can also be a challenge.

I think it is really important to take care of this Critical Code Mass if you do not want to let your program behave like a black whole. This evolution of the code is silent and do not appear suddenly. If all the development team is not aware of this and do not pay attention to avoid it, the projects evolutions will become more and more difficult and long.