[Thoughts] - Development for clients
This is more like a thought blog, it features, thoughts, past, Windows, Visual Basic and clients, if you do not want to read about any of these, you can bail out and read other articles on this blog that have something to dow ith iOS, mobile, lua and some frameworks.
I tried to shake you off, you are still here, ok then, let's continue onwards on this article.
The languages available to work with were the in-buit Basic interpretter or the Machine Language using a series of pokes. There was no StackOverflow, Google or even fiver, elancer, etc to get your ideas into code, most would sit designing the entire game on paper and then painstakingly first create the graphics using a series of numbers poked into the UDG (User Defined Graphics) or creating custom 8x8 pixel fonts and then loading them as active and thereby getting more characters (and levels).
Rather than get into a trip down memory lane, the important fact is that this provided insights to something that made one conciously think of constraints in terms of CPU power, memory and space. Something that many developers do not take into consideration given the large amounts of space available these days. That is one of the reasons that a simple app update can reach 100+ MB. In most given situations, the code/logic when compiled would be hardly 1 MB, the rest is all the add-on frameworks, resources (Graphics, sound, video, etc). In the 90's I recollect the discussions around how should one design a database, should one use a bitmapped index or a bit to represent a boolean or a character. These days if you were concious, your discussion would be that size should an Int be, because you can have an Int8 all the way up to an Int32 or an Int64.
This is a very intersting and important bit, because if you look at the sheer ingeniousity behind how this worked, it is still applicable even today. There are so many developers that find Core Data and Linq to be a bit too complex and have their solutions that maps JSON data with fields or class members. Talk to the new startups, for them this is old stuff, yes it is as it is technology that was developed a couple of decades ago and instead of adopting it with the time, it has been discarded and not looked into (unless a researched looks at it, publishes a couple of papers and then it is the HOT BUZZ technology). In many other cases a lot of ideas are used for things other than they were created for. To cite an example, paper and gunpowder are two technologies that were revolutionary (no pun intended) we use one for the reason it was enhancing it to make a bigger bang (pardon the pun) however the world uses paper for anything but what it was intented for (specailly the western world).
Source: hallofshame.gp.co.at
It is nice to have GUI as they are easier to understand however they still suffer from the cultural contexts (which is for another article) Colours and Symbols have conflicting meanings, however many symbols have been standardized and we have all gone through the various Winds of UI Changes. Currently we are all at the crux of Flat design from a skeumorphic realism (which actually transformed a device to another device) The flat design is nice and easy on the eye, but it does not transform the device, it highlights the device as a conduit (not the point of debate for this article)
Source : Google Search, Copyright the blog it features on
Source: CartoonStock.com
So, when clients approach agencies or developers, they are quoted and charged HUGE amounts of money. Some may argue that the billing in propotionate to the quality of work, in that case many of the agencies should actually work for free. The point is at one time software was freely available (pirated) and if you purchased a computer, the incentive to buy a larger HDD was to have more apps pre-installed. So if you had a 10MB or a 40MB Drive (Yes, you read correct, 10 *MB*) you could have more programs. Programs came on floppies, and depending on the application were anything from 1 to 5 1.44 MB floppy drives. Custom developed software was expensive and there were no outsourcing setups that you could look to for cheaper development rates. Organisations had to purchase systems, not everyone could afford connected/distributed systems so when they purchased these affordable (stil expensive) computer systems, they had to spend to get software that worked for them, there were little off-the-shelf options and developers enjoyed the custom development rates.
Fast forward a couple of years, the technologies changed, from a single Database + Forms type applications (xBase) systems were now GUI based (Windows) and had Client/Server, from Databased, there were Relational Databases to dedicated Database Servers. You could have distributed computing and Remote Procedure Calls, running custom code remotely. Not everybody got this, it was not used by every developer and not implemented very well, if used. However development and computers had become common and available more readily than before. The number of training centres that opened up was simply astounding, the turnovers was phenomenal. Generally speaking, anyone could start a training centre, as there were no regulations around this. The credibility and expertise was demonstrated by flipping a coin (I say flipping a coin for any Objective type test, as the chances of clearning then by someone that has no idea are as random as flipping a coin). These certifications only specified that they knew the specifics of the IDE and the language, there was nothing that taught them about User Guidelines, even organisations did not have CI (Corporate Identity) or branding guidelines, this led to several horrible looking, weird UI's with uneven text box and button sizes. The only advantage to new users was that they could create an executable practically in 2 steps,
1. Start VB
2. Select File -> Make
Done, you might have to create the UI using drag drop and then also write the code, but it was that simple.
The majority of developers learned the syntax but failed to learn the principles behind. From a personal example, in one of the organisations from my past (actually the things witnessed there are good enough to write a book - How NOT to run your business) contracted an outsourcing company to develop custom software for some high profile clients that they were dealing with. The outcome was that they had nearly come down to getting sued for non-deliverance and going over-schedule and over-budget. I am sure many would have heard those three ideas in the 2000's 1. Sued, 2. Over-Schedule, 3. Over-Budget and the reason is simple, lack of basic understanding. This is the major reason why a lot of new words were added and confused the $h1t out of developers. First there were Patterns, now there are Anti-patterns, then there was Extreme programming, Agile Methodology, Lean Development and the list goes on. This would continue because the fundamentals are missing and the unfortunate thing is that instead of realising these project managers continue to cover it up with adding more stuff.
Most of the development that I recollect was always in smaller increments and included user acceptance and I am talking about mid 90's which is about 20 years ago. I did not know it was called Lean Development or that it was a prototype or a Minimum Viable Product. However due to the following this methodology, all of my projects were on schedule and on-budget. Going back to the example of the high profile clients that came to litigation, I was brought in (not as in invited because I am an expert at that time, it was more like OK we give up, let's see what can he do). I could not utilise the two developers directly or delegate any instructions to them, could not provide them with any code review all of that would be managed by their larger team back in another country. On top of that for deployment, I was provided a resource that had his own agenda about surviving in the organisation. Rather than go into details [TL;DR], the code was unnecessarily complicated, overtly crowded UI, multiple complex SQL Queries to fetch data. The end result was that there were 3 sucessfull implementations and the clients were still unhappy but had something working for them. The thing that gets me is why do organisations that have huge teams complicate the whole process than simplifying it.
Here is a simple screenshot that I had build to demonstrate in our internal meeting,
This little vb exe was given to them to play with (Prototype) that was made in one evening following the meeting. From the screenshot you can see it was a POS type app. This was supposed to work with a Barcode scanner, so the user would scan or type the itemCode (the textbox would auto complete from a database of products) alternatively the product could be selected by name (Auto completing combo box) and it would then populate the batches (or related information). When an item is selected, the Stock is dislayed at the bottom and it also indicates the quantity in Packs or Loose. These days you can only purchase complete packs, then you could buy loose, in this case the only hierarchy was to indicate the pack size to create loose items. The total is displayed in green like a dot-matrix display as it would be on a POS system (which was a custom control created in a couple of minutes, not using LCD font as many would these days). The speed of retrieval is so fast even if it transverses through over 5000 items. The other elements to manage payments, etc were not added to this at this stage (Minimum Viable Product). This was made in 2003, about 12 years ago.
Source: Pozool POS, Google Play
Copy these steps listed below and you have your app looking like any other app but people will give it a second and possibly a third look.
1. Add a Map on one of the screens with a couple of annotations
2. Create the Dashboard with a persons face in a circle with their name and social media details below
3. Create a chat like screenshot with a couple of chat bubbles, doesn't matter what they say
This happens because this is the thinking of majority of the investors, imposed by designers. If you also make a video, take or construct a longish screenshot from your facebook account and simply scroll the screenshot, you have it - An AMAZING APP
The art of development is lost, not that I am an activist lobbying for the lost art of development, I am just one random person amongst the billions. My feeling is that the more we shall be dependent on technology and development, the deeper we shall sink into this sinkhole/quicksand. Majority of the code these days is cut/paste, very few developers (there is number of amazing devs that make amazing breakthroughs, but the majority simply use others code) think about the problems and because of that inherit the flaws of the developer's code into their code. "The strength of the strongest chain is as strong as the weakest link".
I tried to shake you off, you are still here, ok then, let's continue onwards on this article.
Development
When I started writing computer code, computers were not mainstream. Offices used typewriters and manual registers to record various stuff. Home-computers were plugged into TV's and even banks did not have computerization, but had demosntrations that computers would mean loss of jobs (not that I understood much of that as I was not part of the workforce at that time). The way software was distributed was via cassettes, where as larger organisations had punch cards, magnetic spools, etc. As kids that swapped Baseball cards, or later swapped Nintendo Gameboy/DS catridges, we used to swap the cassettes and it was really heartbreaking when someone had a mis-aligned tape head or a faulty tape player and the cassette (magnetic tape) came back damaged.The languages available to work with were the in-buit Basic interpretter or the Machine Language using a series of pokes. There was no StackOverflow, Google or even fiver, elancer, etc to get your ideas into code, most would sit designing the entire game on paper and then painstakingly first create the graphics using a series of numbers poked into the UDG (User Defined Graphics) or creating custom 8x8 pixel fonts and then loading them as active and thereby getting more characters (and levels).
Rather than get into a trip down memory lane, the important fact is that this provided insights to something that made one conciously think of constraints in terms of CPU power, memory and space. Something that many developers do not take into consideration given the large amounts of space available these days. That is one of the reasons that a simple app update can reach 100+ MB. In most given situations, the code/logic when compiled would be hardly 1 MB, the rest is all the add-on frameworks, resources (Graphics, sound, video, etc). In the 90's I recollect the discussions around how should one design a database, should one use a bitmapped index or a bit to represent a boolean or a character. These days if you were concious, your discussion would be that size should an Int be, because you can have an Int8 all the way up to an Int32 or an Int64.
UI's
When the UI is a simple matrix of 80x24, like a tileset and each cell can hold a tileset or a character, it is easy to work and manage it, the model was simple, it was a data driven card based screen. In the simplest of examples, a UI card was defined by specifying the locations where you wanted particular text or textbox to appear, and then start reading the screen till the submit button was reached, at this point the data could be saved directly into the database or could be validated before saving. This is specifically how the xBase products worked, all of dBase, FoxBase, FoxPro, Clipper, etc. Since there was no concept of classes at the time, Linq or Core Data would be a little off/confusing, but if you remove the object, you could simply dump the current record to memory variables that you could edit/play with on the screen and then when done, gather the data to save back to the record.This is a very intersting and important bit, because if you look at the sheer ingeniousity behind how this worked, it is still applicable even today. There are so many developers that find Core Data and Linq to be a bit too complex and have their solutions that maps JSON data with fields or class members. Talk to the new startups, for them this is old stuff, yes it is as it is technology that was developed a couple of decades ago and instead of adopting it with the time, it has been discarded and not looked into (unless a researched looks at it, publishes a couple of papers and then it is the HOT BUZZ technology). In many other cases a lot of ideas are used for things other than they were created for. To cite an example, paper and gunpowder are two technologies that were revolutionary (no pun intended) we use one for the reason it was enhancing it to make a bigger bang (pardon the pun) however the world uses paper for anything but what it was intented for (specailly the western world).
It is nice to have GUI as they are easier to understand however they still suffer from the cultural contexts (which is for another article) Colours and Symbols have conflicting meanings, however many symbols have been standardized and we have all gone through the various Winds of UI Changes. Currently we are all at the crux of Flat design from a skeumorphic realism (which actually transformed a device to another device) The flat design is nice and easy on the eye, but it does not transform the device, it highlights the device as a conduit (not the point of debate for this article)
Crowding / Organised UI's
The text interfaces that we discussed above were acceptable by users, the UI guidelines were simple, the enclosing group had the text and dashes or ASCII characters to create a box around the related textfields. The textfields were generally with a single line spacing unless they were fields like address or notes (multi-line text fields). This worked well for a very long time also because legacy systems be it running RPG, Cobol, xBase, etc they worked fine with the 80x24 text screen. Computers became more popular and there were shells that provided visual access to the files and programs, etc. There was DosShell, Norton Commander that I can recollect from the top of my head and then there was Windows 3.1. A lot of users wanted to use a nice looking white screen as against the black screen that they were used to, in addition to the nice graphic icons and a *GASP* mouse to access the various sections. Users were used to moving a cursor with the keyboard, (for those that might balk at the idea and ask HOW is it possible) well it was, it was almost like using the keys like in a game to move the characters on the screen, you moved the mouse pointer instead. So the developers that had contracts and contacts ported their textual UI's onto the new GUI based programs. This started the trend of the overcrowded complicated text boxes on a screen. Despite the fact that Microsoft had offered several articles and resources and even controls to segregate the controls and text into managable chunks, for some strange reason they were never used.Overcomplicated and Overbudget
It is interesting that many people I have spoken to in the recent few weeks, including some guys from large Tech Corporations that deal with billions of dollars of technologies and development, the one thing that was a bit disappointing is that their view on the future is not built on a sure step from the past. In other words, their valuation of something is on the current value and use. This kind of thinking is one of the reasons why the world faced the GFC and the reason why the generation is "I want it all and I want it now" because they are not ready to learn FROM CERTAINITY, they are ready to ONLY RISK and the best part is that the risk costs them nothing but the gambit pays quite well. This mentality cannot be changed and beyond the scope of the discussion of this article. I know one thing for a fact, if most of these people were left in a situation without their tech, they would be unable to do anything. Now you do not have to be McGwyver, but it is important to know the basics and the WHY and the HOW of things.So, when clients approach agencies or developers, they are quoted and charged HUGE amounts of money. Some may argue that the billing in propotionate to the quality of work, in that case many of the agencies should actually work for free. The point is at one time software was freely available (pirated) and if you purchased a computer, the incentive to buy a larger HDD was to have more apps pre-installed. So if you had a 10MB or a 40MB Drive (Yes, you read correct, 10 *MB*) you could have more programs. Programs came on floppies, and depending on the application were anything from 1 to 5 1.44 MB floppy drives. Custom developed software was expensive and there were no outsourcing setups that you could look to for cheaper development rates. Organisations had to purchase systems, not everyone could afford connected/distributed systems so when they purchased these affordable (stil expensive) computer systems, they had to spend to get software that worked for them, there were little off-the-shelf options and developers enjoyed the custom development rates.
Fast forward a couple of years, the technologies changed, from a single Database + Forms type applications (xBase) systems were now GUI based (Windows) and had Client/Server, from Databased, there were Relational Databases to dedicated Database Servers. You could have distributed computing and Remote Procedure Calls, running custom code remotely. Not everybody got this, it was not used by every developer and not implemented very well, if used. However development and computers had become common and available more readily than before. The number of training centres that opened up was simply astounding, the turnovers was phenomenal. Generally speaking, anyone could start a training centre, as there were no regulations around this. The credibility and expertise was demonstrated by flipping a coin (I say flipping a coin for any Objective type test, as the chances of clearning then by someone that has no idea are as random as flipping a coin). These certifications only specified that they knew the specifics of the IDE and the language, there was nothing that taught them about User Guidelines, even organisations did not have CI (Corporate Identity) or branding guidelines, this led to several horrible looking, weird UI's with uneven text box and button sizes. The only advantage to new users was that they could create an executable practically in 2 steps,
1. Start VB
2. Select File -> Make
Done, you might have to create the UI using drag drop and then also write the code, but it was that simple.
The majority of developers learned the syntax but failed to learn the principles behind. From a personal example, in one of the organisations from my past (actually the things witnessed there are good enough to write a book - How NOT to run your business) contracted an outsourcing company to develop custom software for some high profile clients that they were dealing with. The outcome was that they had nearly come down to getting sued for non-deliverance and going over-schedule and over-budget. I am sure many would have heard those three ideas in the 2000's 1. Sued, 2. Over-Schedule, 3. Over-Budget and the reason is simple, lack of basic understanding. This is the major reason why a lot of new words were added and confused the $h1t out of developers. First there were Patterns, now there are Anti-patterns, then there was Extreme programming, Agile Methodology, Lean Development and the list goes on. This would continue because the fundamentals are missing and the unfortunate thing is that instead of realising these project managers continue to cover it up with adding more stuff.
Most of the development that I recollect was always in smaller increments and included user acceptance and I am talking about mid 90's which is about 20 years ago. I did not know it was called Lean Development or that it was a prototype or a Minimum Viable Product. However due to the following this methodology, all of my projects were on schedule and on-budget. Going back to the example of the high profile clients that came to litigation, I was brought in (not as in invited because I am an expert at that time, it was more like OK we give up, let's see what can he do). I could not utilise the two developers directly or delegate any instructions to them, could not provide them with any code review all of that would be managed by their larger team back in another country. On top of that for deployment, I was provided a resource that had his own agenda about surviving in the organisation. Rather than go into details [TL;DR], the code was unnecessarily complicated, overtly crowded UI, multiple complex SQL Queries to fetch data. The end result was that there were 3 sucessfull implementations and the clients were still unhappy but had something working for them. The thing that gets me is why do organisations that have huge teams complicate the whole process than simplifying it.
Here is a simple screenshot that I had build to demonstrate in our internal meeting,
This little vb exe was given to them to play with (Prototype) that was made in one evening following the meeting. From the screenshot you can see it was a POS type app. This was supposed to work with a Barcode scanner, so the user would scan or type the itemCode (the textbox would auto complete from a database of products) alternatively the product could be selected by name (Auto completing combo box) and it would then populate the batches (or related information). When an item is selected, the Stock is dislayed at the bottom and it also indicates the quantity in Packs or Loose. These days you can only purchase complete packs, then you could buy loose, in this case the only hierarchy was to indicate the pack size to create loose items. The total is displayed in green like a dot-matrix display as it would be on a POS system (which was a custom control created in a couple of minutes, not using LCD font as many would these days). The speed of retrieval is so fast even if it transverses through over 5000 items. The other elements to manage payments, etc were not added to this at this stage (Minimum Viable Product). This was made in 2003, about 12 years ago.
Point of this?
Development is not about simply billing the client, it is about building something, a product that helps the client transform their business and help them create more opportunities to enhance their business. It does get to me when many non-technical project managers approach development with a hammer and get things in place, many a times damaging the very critical and essential strands. The other things that gets to me is that the only criteria that people have to judge the worthiness of a software is based on the glossy screenshots.Copy these steps listed below and you have your app looking like any other app but people will give it a second and possibly a third look.
1. Add a Map on one of the screens with a couple of annotations
2. Create the Dashboard with a persons face in a circle with their name and social media details below
3. Create a chat like screenshot with a couple of chat bubbles, doesn't matter what they say
This happens because this is the thinking of majority of the investors, imposed by designers. If you also make a video, take or construct a longish screenshot from your facebook account and simply scroll the screenshot, you have it - An AMAZING APP
The art of development is lost, not that I am an activist lobbying for the lost art of development, I am just one random person amongst the billions. My feeling is that the more we shall be dependent on technology and development, the deeper we shall sink into this sinkhole/quicksand. Majority of the code these days is cut/paste, very few developers (there is number of amazing devs that make amazing breakthroughs, but the majority simply use others code) think about the problems and because of that inherit the flaws of the developer's code into their code. "The strength of the strongest chain is as strong as the weakest link".
Comments
Post a Comment