Technology curve for Agile development à la development from the basics

So let we see how a development curve look like if we use some very general and basic environment for out development. From a theoretical point of view it is something like a Turing machine, although surely nobody programs Turing machines. From a practical point of view it can be some very general programming language and environment, like C or C++.

Set up time: Almost no setup time or cost: at most installing a basic environment and or setting projects team.

Effective development phase: It is pretty much questionable if one can speak about effective or agile development phase for this scenario as setting up the business cases requires a lot of efforts as everything has to be implemented from scratch.

Architecture limit: Practical there is not architecture limit apart from some theoretical ones like uncountable languages. However on a long run there can be some practical limits, if the already implemented amount code needs to be reconstructed.

Figure 1. Technology curve for developing from basics.

ERP versus Business Applications

ERP versus Business Applications

Product, Rapid Aplication Development and classical programming compared

Product, Rapid Aplication Development and classical programming compared ... from the customer perspective...

Meme theory and economics ?

And three most important questions for tonight :
1. Does a fashion trend exist because a lot of people think that the given stuff is fashionable ?
2. Does a fiat currency have got value because a lot of people think that the given fiat currency should have a value ?
3. Does gravity exist because a lot of people think gravity should exist ? ... ?

Bear market strategy on IT markets

Market goes up, market goes down, however the major question what to do if you are on a technology market and the technology goes down. 

Well certainly there are some trivial things that you can do, like

- If you have stocks sell

- If you have the competence do not invest to keep the competence up-to-date in anymore.

- If you have competent people on the field let them reeducate. 

- If you have product on the field then stop them to develop further.

However the problem is that with these strategies you only quit from the technology, stop investing, but without making money.If we are on the stock market and the market goes down than sell short to make profit. Is there any similar step if you are coicdently not on the stock market ?  

Well difficult question....Let we see what happens if a technology goes down:

- Selling the new technology is being reduced. 

- Existing customers do not upgrade and invest into the technology, instead they leaving the technology to expire.

- Existing customers start the new projects and investments in another technologies. 

- On a short run there will be more expert and developer on the field than business opportunities, as a consequent consulting and development price decreases.

On a long run, it might be that it is worth to stay with the technology, because it is right that the market is smaller, but as the number of experts are limited as well there is still a chance to do good business. I guess one example is dor instance AS400, the technology itself is pretty much old and used only by a couple of companies. However as there is only a handful of companies that have the high expertise, the market itself is profitable.

So what are the other options :

- Investing on alternative technology: As one technology goes down another one is coming up. New projects will be probably in the new technology.

- Building migration tool: building migration tool to another technology that is coming up can be a good idea. As the customers considering the change of technology the companies will have the advantage that are prepared to migration. 

- Create integration: focus on integration with an alternative technology. Most customer still have the old technology, however as a further development they rather focus on new ways. For such scenarios integration can be good idea.

- ??? good question what is still possible ???    

Technical requirements of ERP systems

Notes on Turing test

The Turing test is a test of a machine's ability to exhibit intelligent behavior equivalent to, or indistinguishable from, that of a human (Link to Wikipedia). 

As Turing test generally pretty difficult to pass for a machine the question how difficult is to have a Facebook Turing test. I mean supposing that your software posts weekly a couple of pictures quotes and emotions, and commenting some specific topics, like for a topic animal lovers : wow, I like, dogs... or something that is just a little bit more as a bullshit bingo.

I mean is there really a chance to identify only via Facebook if someone is a human or not ?

A trial to semantically describe a blogging software aplication

This is a first trial to semantically define a software application. I try to describe a simple blog application with the help of a pseudo XML like language. The primary importance does not related on how the language exactly look like, instead to define if there is realistic chance to define internal elements a software application without in a precise form but with the help of a formalism.

As I previously remarked a usual software application has got the following elements to describe:

- Data model or entity model containing entities, properties, types and hierarchy between these elements.

- Service model: the possible services that are realized on the top of the entity model. Workflows can be be regarded as special subcategory services. 

- User Interface: User interface elements to give access for the realized services. Reports can be regarded as special user interface elements.

- Right model: detailed description who should have access for which components, for which entity, property, service or user interface component.

Right model: Right model contains three groups: readers having read access overall, contributors having write access and admins being administrators.

<GROUP> Readers 
<GROUP> Contributors 
<GROUP> Admins 

Entity model describes properties and entities and a right model association, who should have a read or write access for what.

<ENTITY> Blog
 <PROPERTIES>
   <PROPERTY> Title <TYPE> {Text} 
   <PROPERTY> Content <TYPE> {Richtext} </TYPE>
   <PROPERTY> Labels <TYPE> {List of : Labels} </TYPE>
   <PROPERTY> Create Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Publish Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Created By <TYPE> {User} </TYPE>
   <PROPERTY> Last Modified By <TYPE> {User}
   <PROPERTY> Publish State <TYPE> {Choice : Draft, Published}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

<ENTITY> Label
 <PROPERTIES>
   <PROPERTY> Label Name <TYPE> {Text}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

Service model describes two group of services, on the one hand the classical create read update delete services, on the other hand a group of publishing servicing.

<SERVICE GROUP> CRUD

 - <SERVICE> New Blog
      <INPUT> {Entity : Blog}
      <TODO> <Set> Created By, Last Modified By= Current User  
           <Set> Created, Last Modified = Now
           <Set> PublishState = Draft
     <OUTPUT> null
     <ACCESS>
       <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Update Blog
      <INPUT> {List : Blog keyproperties}, {List : Blog properties}
      <TODO> Find blogs based on keyproperties and update on Blog properties
      <OUTPUT> null
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Delete Blog
    <INPUT> {List : Blog keyproperties}
    <TODO> find elements that match on the keyproperties and delete
    <OUTPUT> null
    <ACCESS>
       <EXECUTE> Contributors, Admins 

<SERVICE GROUP> Publish

 - <SERVICE> Publish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Unpublish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Draft
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Published Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties, where Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Readers, Contributors, Admins 

User interface model: Last but not least user interface elements should be described. For the first run two sites an all blog and an admin blog sites are defined.

<SITE> All Blogs
  <SERVICE> Read Published Blog
    <INPUT> null
  <ACESS> Readers, Contributors, Admins

<SITE> Admin Blogs
  <SERVICE> New Blog
  <SERVICE> Read Blog
    <INPUT> null
   <OUTPUT> list of all blogs
  <SERVICE> Update Blog
 <ACESS> Contributors, Admins

Conclusions :
- As one can intuitively think that describing such a simple application is easy, in the practice it can be pretty complex.
- It is questionable how complex should be the user interface. Is it really enough to describe the sites and the services on the site and the rest practically just design, or is it better to define a detailed user interface model.
- It is questionable how the navigation should be defined. Is it part of the user interface description or is it better to define as a service.
- The components should rather be defined as general templates that are easily combined with each other, like CRUD or Publishing services independently from the data model, or Read and Write groups independently of the services or the data model.
- Supposing we want to have an administrator functionaries, it is questionable how they can be realized. Perhaps with the help of meta modelling and meta services.

Brief History of Money

Notes on Money

On of the reason of the appearance of money that it improved the exchange of goods and services : See Wikipedia . However with the appearance of the internet and online trading it can be imagined that the direct barter is effective enough to realize and effective exchange without using money. 

So let we say I can provide a certain service portfolio that I want to exchange, like as I am originally a software developer I can provide the following set of services SOFFER = { SDEVELOP_DOTNET, SDEVELOP_C#, SDEVELOP_JAVASCRIPT }. On the other hand I need a certain service portfolio practically to survive, like I need meat each day, water, electricity : SREQUIRE = { SMEAT, SWATER, SELECTRICITY }. So let we say each actor on the world has got a certain set or certain portfolio of services to offer and a certain portfolio of services to require. With the help of internet and online exchange it is pretty fast to find someone that needs the same portfolio that we provide and has got the same portfolio that we need. However it is absolutely not sure that such a direct match exist. As a consequence a direct barter network would have at least the following two challenges : 

1. Considering a certain network of actors who can provide and requires certain service portfolios how is it possibly to have a "best match", meaning that finding the actors that provides the services that I need and vica versa finding the set of actors that need the services that I provide. The simple "Best Match" probably require further complex graph theoretical investigation, although there is a little bit questionable if there can be defined a "Match" if I provide my services to multiply actors and I get the services from multiply actors as well. 

2. Trust issue : how it is possible to guarantee that all actors can be trusted, meaning that the negotiated services are really delivered.