Engineering

SOA Manifesto

Recently I discovered that during 2nd International SOA Symposium they published SOA Manifesto. It follows the spirit of the famous Agile Manifesto, which provoked many discussion and debates over the actual meaning of the statements of that manifesto. (Not) surprisingly there are many other manifestos related to software. Here are some to name a few:

But there is important thing, which puts SOA and Agile manifestos apart from others -- they can not be simply declared by an individual to work. While one can accept, for example,  the GNU Manifesto and act as declared and make a difference. With SOA and Agile you can not manifest something individually -- the team has to embrace these ideas together in order to make them work.

I wonder when (and if) we will move to team manifestos instead on manifestos of individuals.

,

Weekend reading: software complexity

,

paper_clipLast weekend we kind of explored the field of software estimation, so it is about time to see, why it is not an easy task. Complexity is what makes estimating hard.

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

-- Jerry Weinberg, Quality Software Management Vol 1, Chapter 9

And here are some more links to explore the topic:

What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

,

Weekend reading: Software projects planning and estimation

,

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

  • Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
  • 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
  • Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
  • Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
  • Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.

,

End of desktop OSes?

,

These days there is many buzz around recent announcement of Google Chrome OS. This is, probably, first loud announcement of development of new desktop OS since 2000 when Apple announced its Mac OS X. Of course, if we do not take mobile OSes into account. There are many discussions around what this means to computing. And, in my mind, this is important event, because it manifests end of desktop OS. 10 years ago you used your OS to run applications, now you use OS to access the Internet. As soon as computer became a means of accessing Internet, OS become irrelevant, because the Web-browser is the new laptop:

At this point, who cares what operating system you run? Choice of web browser will have a far more profound impact on most people's daily lives.

We've seen this in cell phone world for years: phones are not a platform for running applications, they are means of accessing cellular network. It does not matter which software is used to operate the phone. Nobody gives a crap about phone software, as long as it allows to place and receive calls with some level of convenience.

The same thing happens to computers now. It is now time, when you can actually create an OS, which will be used by audience larger than its development team. As long as it will be capable of establishing a Wi-Fi connection and executing a web-browser with JavaScript and XHTML support, all the rest will be less important.

"Time to Web" (time from the moment user powers up a computer till Google is loaded in the browser) for a computer+OS tandem will be defining a winner in today's and tomorrow's market of computing. The same way as time to repeat last call was once important for cell phones.

Today "time to Web" determines how fast you can access your e-mail, your text editor, your spreadsheet, you video and TV, your newspaper, your everything. Yes, Web-apps are usually less functional than their desktop counterparts, but as Leo Babauta says:

We don’t need feature-bloated Microsoft Word anymore. Nor Excel, with its 2 million features, nor PowerPoint (who likes to watch slides?). Sure, there are still some great desktop apps that people use, for photo and video editing and much more … but the majority of us don’t need those. We need to communicate simply and quickly, without hassle.

Web apps don’t match up with desktop apps … but that’s a good thing for most of us who use the new computing model.

Now, that we have for quite a time in-kernel Web-servers, I wonder how long it will take to create in-kernel web-browser.

, ,

What is a solution?

, ,

I love the definition of solution from old good MSF 3.0:

Solution is the coordinated delivery of the elements needed (such as technologies, documentation, training, and support) to successfully respond to a unique customer’s business problem.

There several things in this definition that appeal to me:

  • It clearly separates solution, developed with specific customer in mind, from product targeted at market, as also outlined in MSF Process Model.
  • Customer's business is in the center of attention. And if the best way to address this problem is not development  of new software, so be it - it can be as simple as re-engineering existing system and providing adequate documentation or training; or instead of throwing development effort at scaling problem, one can just add more hardware capacity. Again, in case this is the best approach.
  • There is no place for technology bells and whistles. If a mere VBScript can solve the issue, why waste precious time and resources on ultra-modern super-cool JavaFX (no offense here) development, if it does not add anything valuable for business?
  • At last, technology is not a sole focus of solution development: delivery, documentation, training, etc. are equally as important.

Be sure to deliver your customers solutions and not just software pieces. "Software installed" is not a goal here, "problem solved" is.

Platform independence vs. Platform interoperability

There is a very interesting passage by Jurgen Appelo of NOOP.NL, which is almost completely unrelated to the idea of the post about book reading hack:

I don't want to read chapter 20, which is about platform interoperability, which I find completely uninteresting. (Let's face it: wanting to be platform-independent so that you can easily switch platforms, is just as useful as wanting to be bisexual, because it easily enables you to switch genders. Not many people think that's very important.)

While I agree with such a bright comparison of platform independence, platform interoperability is another beast. While you can kill yourself trying to have one product working equally good on different platforms, you not only may need to, but in our fast moving world have to, interoperate with other applications. And sometimes only God knows, which platform they run on.

,

Software quality as a practical metric

,

All of that started with Twitter... I created an account on Twitter. My way to Twitter was quite long and there were, I guess, 3 major factors that made me do that: changes in my professional life, Bob Walsh's comments about Twitter and Hanselminutes episode about WPF Twitter client blu. In my 2 or 3 days Twitter "career" I've already seen famous "Something is technically wrong" so I can see myself as an experienced Twitter user.

But there are 2 other things that prompted me to think about software quality.

After listening to Scott Hanselman's podcast I installed blu. The second thing I noticed after slick UI was inability to work through proxy. I live and die by personal proxy which allows me to easily migrate between different networks during my day. So, what can I say? Nice piece of software, but almost completely unusable in my setting, which as I would guess is not uncommon.

Another sad experience is twitbacks. As a newbie I given in to temptation of working on form rather than the meaning first. I've spent quite a time with this tool, but was not able to produce any sufficiently good looking background. Main issue for me was strange resizing which made text blurry and also lead to incorrect alignment with functional elements of the Twitter page. Again, nice idea, but not usable.

Both of these cases look to me as an obvious shortcuts taken by the development teams on requirements definition or testing stage. Quality of the system output is determined by weakest link in the system. Determined to the extent that piece of software may be rendered unusable in certain common scenarios.

Network client solution cannot omit widely spread variances in Internet connectivity settings.

Image generation software can not afford generating funky images.

Check that you have not fallen into the same trap or start fixing that immediately.

Technology adoption curve

Did you know that Microsoft recently added Mobile RFID to BizTalk server?

This event alone does not have an outstanding impact on the industry, but inspires some thoughts. Generally, each technology or product has (or has to have) two stages of realization, two waves of value generation:

  • Vendor invests into product development and realizes its value by selling to customers.
  • Product consumers invest into product deployment and learning and realize its value by generating revenue for themselves.

In general, this means that while they fully undergo their curve consumers are not ready to adopt new technology. Usually, you will not embarrass deployment of new technology until you realized the investment in previous.

This means that there are some natural limitations on how often vendors can release new technologies/platforms/products. If they release too often customers are not ready yet to make new investments and technology adoption will be hindered. If release cycle is too long less revenue will be generated.

Of course, these waves are smoothed over by large number of customers out there in the market, each in different phase of technology deployment; by number of vendors offering competitive products; and by a whole lot of other factors. But still it is important to understand these waves to build a successful marketing and release strategy.

Think of customers' pains and try to relief them not to amplify by asking to deploy new product when he is having hard times returning the investment from previous.