This post is about frameworks, toys, design, usability, copy/paste and education.

I recently had the chance to help some friends to build a new on-line store.

The story line is important because it reveals important aspects about application architecture. This new and soon to be famous HandsOnEducation on-line store for educational toys begun in November 2009 when they bought some famous brands and started their business. Because the friends I am talking about had experience with other ERP software I considered a minimal introduction would be enough, so I explained to both of them the basics of the OptimusERP, gave them the CHM manual and decided to offer support if things go bad. It was a pleasant surprise to hear that they managed to discover very quickly how to input in the application the “Received Invoice” and to follow all the steps which will make the products appear in the stock. Due to an exhibition they were supposed to be present (something about kids) they did not have the time to input all the received invoices.

The OptimusERP is based on a 3-Tier architecture functioning very well on low speed connections (even 64Kb), but due to the crowded atmosphere at the exhibition they decided to sell “off-line” and to input the data in the application afterwards. Finishing late and starting early, everybody was too tired to be able to type in the data at the end of the day, so they decided to type in after the show.

Immediately after the exhibition, the first customer came on-line and made a significant order (it was about 100euros, a hand constructible Eiffel Tower). The invoice was introduced in the app, the warning messages ignored and everything went well. The customer paid, money received. Other customers came, things got busy again, but well it’s good to sell…

Several days passed and they managed to enter in the application all the invoices, received and sent. I was asked to help them see the stock values. It is now I realized we missed an important point. A part of the application was configured to allow negative stock, and we used it as it is. So actually we informed the system to sell me objects which I hadn’t yet in the database. No problem I said. Let’s call a consultant and see what options we have.

As you might imagine the only option was to remove all the sent invoices which were introduced before the stock was populated with items, and input them again. I kindly asked them to do this, while helping them to do it faster. After finishing with this we found out that due to fatigue we missed the selling documents at the exhibition. So decided to input them also. As you can imagine that is prior to all the selling we performed. After typing them in, the stock was OK finally, but with one problem: the prices in the stock. This is another important accounting thing because of a FIFO option we had, so this must be corrected also.

In conclusion this lead to two late evenings working the OptimusERP to retype in almost all we had, in the correct and proper order. Doing this on a daily basis, 5 invoices per day is ok, but to type 20 per hour is not so funny. I cannot tell how much I missed the old copy/paste, the EXCEL tables and the undo of Word. I discovered in these hours some major improvements we should perform to our app which I will share with you.

Please note these are not particular problem of our ERP, we designed and implemented it according to “proven” architectural guidelines, well marketed techniques, using best-of-breed frameworks and so on. A lot of the products on the market are designed this way.

Here is what I learned:

1. No complete training course leads to many later phone calls.
2. Critical warning sign ignored might lead to inconsistency in stock values
3. Adding in selling invoices in the improper order and skipping invoices messes up your stock operations
4. A document is not a set of records, it’s a document. It should be kept as a whole until you decide to input it in the application and be processes.
5. Undo is a bless, undo should exist for everything. I know a certain order should be preserved but it’s not impossible.
6. People like to be able to type in a document even if it’s not consistent with your database. Let the checking of consistency/validation for a later step.
7. People like copy/paste of documents or cells in tables/etc. Record based/web based systems are not copy/paste friendly. Hardly you can copy a set of records.
8. The critical reports should be presented to the user early on.

Starting a new business goes with a lot of enthusiasm and I believe my friends at HandsOnEducation have more than what it takes to make this move. Helping them starting off helped me realize once again how important is to actually put yourself in your customer’s shoes.

In the next post I will share with you the changes we performed in the architecture and usability of our app and how did the educational startup receive them.

This article is inspired by Udi’s post Non-functional Architectural Woes.
“This is how the business has been done for decades and will continue to be done for decades more” (Udi Dahan 2010)

As we build enterprise systems we are confronted with continuous change in the business requirements while the business as a whole remains the same as time goes by.

In a previous post i was investigating the possibility to indentify and cover the entire scope of the project using fractal theory. Based on the fact that scope of a project is discovered as we and are constructing the system, a method for uniformly (in terms of distribution) discovery of new parts of project scope would be appreciated.

One might notice that business objectives resembles to its business area, but are also somehow particular. The more you add businesses objectives together the more they look closer to the whole industry pattern. The more you dive into one’s business speciffic objectives, the more you find differences from the industry though keeping an resemblance to the whole. Makes me think again to fractal theory. The attached movie shows how a mathematical figure (the Mandelbrot set) is zoomed in and shows us details about it’s composition and resemblances of the initial picture.

As Udi says, and I kind of agree, the architectural pillars we should be interested in discovering while building an application should be close related to the functional requirements, more specifically business objectives. Decomposing the business objectives into smaller objectives (specific to the particular business and not the the whole) is quite hard.

It is not hard to decompose business objective into smaller ones because we don’t know how, it is hard because we have no clear knowledge on how to identify the real valuable objectives and to cover all of them. We should seek the method for covering all, the method for identifying the processes valuable, all-in-one the method (the fractal function as one might say). And if this method is applied over and over it might guarantee that we are able to find the all the most valuable objectives which if implemented might lead us to a stable business architecture.

You might say that agile methods cover this by iterating and clarifying objectives as the software evolves, whereas Waterfall methods rely on well documented living documents. Both strive to complete the business objectives.

One method, which I can guarantee to work if applied over and over, is to read and comment what other great guys have to say about things you are trying to discover, to be inspired by them and to constantly learn about the targeted business domain.

I watched a nice presentation at InfoQ of John Seddon about Lean Services. He makes a valuable point about identifying costs not in activity but in the process.

Some key points John mades in re-thinking lean services:

1. Do not apply same principles from manufacturing to services

2. Study your process and follow a piece of work from entrance to exit (value work and wasted work)

3. Study demand and see which is predictable and address it using another system

4. Identify system's conditions for creating waste, not activities performed by people

5. Change is emerging, something you never plan for

6. Putting control in the hand of the workers give you more control than you ever had

7. Never manage with targets, never manage with other arbitrary measures unless you're going over a clif

8. Use measures that derive from purpose and put them in the hand of the workers

Both inspirational and controversial I might say.

More resources about him, including podcasts can be found here. 

Hope it helps. 

I enjoyed waching Ron Jacob's ArCast and was quite disapointed when he stopped. It seems he is back with some good materials: WCF for beginners and WCF with REST.

Enjoy

V-ati intrebat vreodata ce se intampla cu programatorii care imbatranesc? Exista pe undeva un cimitir al programatorilor unde acestia se pot duce linistiti sa moara precum elefantii care simt ca li se apropie sfarsitul? 
Oare ce mai inseamna sa fii programator in ziua de azi? Se observa o tendinta tot mai accentuata de a crea noi metode de dezvoltare software astfel incat sa nu fie nevoie de cine stie ce cunostinte de programare, ci mai mult de imbinare de functionalitati deja existente (traiasca "copy&paste"-ul). Aceasta tendinta este una oarecum normala din punctul de vedere al managementului unei firme de IT, care vrea sa iasa pe piata cu produse adaptate fiecarui client intr-un timp cat mai scurt. Toate bune si frumoase, dar ce se intampla cu programatorii? Devin ei oare niste mici robotei care nu fac altceva decat sa arunce intr-un designer de DSL niste obiecte si totul e gata? Daca l-ati intreba pe seful meu, v-ar spune ca asta e tendinta, sa nu se mai scrie cod, ci sa se modeleze entitati de business. Dar noi suntem programatori, nu analisti de business. 
O alta categorie de programatori este formata din cei care scriu framework-ul folosit de toti ceilalti dezvoltatori din cadrul unei organizatii. Acolo chiar e nevoie de programatori adevarati, altfel calitatea framework-ului rezultat lasa mult de dorit. Trebuie sa fie niste programatori foarte experimentati, care sa stapaneasca foarte bine atat conceptele programarii orientate obiect, cat si pattern-uri de design. 
Dar sa revenim la prima intrebare: ce optiuni are un programator care vrea sa "avanseze"?Am auzit destui colegi de-ai mei de facultate care au zis ca e cazul sa faca o schimbare in cariera, ca doar "nu o sa ramana programatori toata viata". Ca si cand ar fi ceva rau. Majoritatea s-au facut project manageri (da, stiu, ce fac oamenii astia exact? :D ), altii pur si simplu au renuntat la industria IT si acum activeaza in cu totul alte domenii.  
O alta categorie este cea a programatorilor care vor sa devina arhitecti software. Cu toate astea putina lume stie exact ce ar trebui sa faca un arhitect software. Cum adica "propune solutii tehnice"? Din ce am mai citit despre arhitectura software, nu pare a fi la indemana oricui. Pe langa faptul ca trebuie sa ai o experienta destul de bogata pe partea de dezvoltare, sa fi lucrat pe multe si variate proiecte, trebuie sa fii la curent cu tot ce e nou in domeniu. Putini pot face asta, poate doar cei pasionati. Ma uitam zilele trecute pe niste anunturi de angajare pe o astfel de pozitie (US, nu Romania, unde chiar exista o piata pentru arhitecti software). Lasand la o parte diversitatea de cerinte pentru un asemenea post (inca o dovada ca fiecare intelege ce vrea prin arhitect software), trebuia sa ai, printre altele, minim 7-10 ani experienta in dezvoltarea de aplicatii pentru Windows in C++. 10 ani! Oare cati din programatorii pe care ii cunosc se pot incadra in astfel de cerinte? Cred ca niciunul. Si atunci, ce sanse ar avea un programator bunicel (nu exceptional) sa devina arhitect? 
Microsoft a lansat de ceva vreme un program de certificare pentru arhitecti (Microsoft Certified Architect Program). Obtinerea acestei certificari nu se poate face in mod traditional (dai unul/mai multe examene si devii arhitect), ci este un proces destul de laborios in care trebuie sa fii audiat de un consiliu de specialisti care, pe baza experientei tale si a interviului propriu-zis iti pot acorda sau nu titlul de arhitect. Se pare ca si cei de la MS sunt de parere ca nu oricine poate fi arhitect…  

In concluzie, ce poate face un programator atunci cand simte ca incepe sa se plafoneze? Optiunile par oarecum limitate. Este trist sa vezi ca a fi programator in ziua de azi se rezuma de fapt doar la a folosi niste tool-uri create de altii, tool-uri care transforma un programator intr-un end-user mai rasarit, cu vagi cunostinte de programare, dar care, fiind intrebat de prieteni cu ce sa ocupa, raspunde mandru "sunt programator". Cand intalnesti astfel de oameni, parca nu iti mai vine sa zici ca si tu esti programator, deja magia a disparut. Asta da moarte a pasiunii…

Prima data cand am primit aceasta intrebare a fost cand mi-am schimbat ultima oara locul de munca. De atunci ma tot intreb si ma tot gandesc ce fel de solutii mi-ar placea sa dezvolt. Sunt un junior in ale’ programarii si inca nu am participat la dezvoltarea mai multor proiecte, dar as putea spune ca toate proiectele la care am luat parte au fost diferite. Consider ca ar trebui sa-mi placa ceea ce fac ca sa am success mai departe si sa evoluez, dar din pacate, inca nu stiu si nu am avut sansa sa cunosc prea multe.

Ca sa-mi raspund la intrebare m-am gandit sa apelez “prietenul” Google si sa intreb pe forumuri si pe alti oameni care au mai multa experienta. Am incercat sa centralizez rezultatele cautarilor mele si sa ajung la o concluzie.

In fiecare zi suntem expusi utilizarii diferitelor tipuri de software ca de exemplu:

Soft de productie: este cunoscut si ca tool software; este folosit pentru a ajuta utilizatorul sa creeze doumente, baze de date si alte produse; niste exemple ar fi: Microsoft Word – pentru a crea documente, Microsoft PowerPoint – pentru a crea prezentari si multe altele.

Soft practic pentru exercitii si rezolvari de probleme: este soft care da utilizatorilor feedback; un exemplu ar fi Matlab-ul, Math Blasters, Splus, dictionare si altele mai ales statistice si matematice.

Soft tip tutorial: ofera utilizatorilor ilustratii, descrieri si simulari pentru a-i ajuta sa invete diverse lucruri.

Soft Multi Media: se refera la programele care folosesc sunete, poze, grafica, animatie, video, text; jocurile pe calculator sau softul folosit pentru simulare de discutii intre mai multi utilizatori(Black Board) sunt doar doua exemple.

Am intalnit destul de des dezvoltarea de soft bancar, care te invata logica si o parte din regulile folosite in banci. Dar pe langa business-ul propriu-zis, acest tip de aplicatii mai necesita si cunostinte destul de avansate de securitate si optimizari de baze de date.

Mi-a mai trecut pe la urechi si soft de tip ERP care am auzit ca necesita cunostinte economice, pentru amatori.

Am avut ocazia sa dezvolt, pentru o perioada scurta de timp, soft pentru aeropoarte; mai exact un soft folosit la urmarirea bagajelor de la punctul de plecare la destinatie, cu scopul de a nu se pierde pe parcurs.

Am intalnit oameni cu mai multa experienta in programare si care au spus ca le place sa dezvolte framework in cadrul firmelor in care lucreaza. Mi se pare una dintre cele mai tehnice si matematice abordari ale programarii. Dezvoltand un framework ai ocazia sa te folosesti de diverse design patterns, o abordare destul de interesanta.

Pe forumuri am intalnit pasionati de compilatoare care m-au pus pe ganduri. La facultate am intalnit si eu cateva notiuni, destul de abstracte, folosite in gandirea unui compilator: gramatici, parsere si tot felul de rescrieri.

Un antivirus, ar fi interesant de dezvoltat, si cred ca necesita tot felul de cunostinte interne ale sistemului de operare. Si ca a venit vorba, de ce n-ar fi interesant de dezvoltat chiar un sistem de operare.

Pasionatii de criptografie pot sa se delecteze cu dezvoltarea unui protocol.

Un tip de aplicatii des intalnite mai ales printer juniori sunt site-urile de perezentari si magazinele virtual.

Softul pentru mobile este des intalnit in ultima vreme, telefonia mobila avand mare amploare.

Jocurile pe calculator sunt un soft destul de complex de dezvoltat.

Softul folosit la gestiunea marfurilor in depozite, sau cel folosit pentru urmarirea alimentelor printre distribuitori au un business aparte.

As putea sa continui cu enumerarea tipurilor de soft, ca sunt convinsa ca sunt destul de multe. As incerca o clasificare dar inca nu stiu ce criterii sa folosesc, motiv pentru care o las pe mana altora, mai priceputi.

Existand o varietate asa mare de aplicatii, in continuare sunt confuza si nu stiu ce sa raspund la intrebarea “Ce soft mi-ar placea sa dezvolt?”.

Drept concluzie si incheiere, o sa folosesc raspunsul la aceasta intrebare de pe un forum:

“Chestia asta e relativa - unora le plac aplicatiile de gestiune/business,  altora aplicatiile web (ex.: portals), altora aplicatiile embedded - doar tu poti decide ce iti place si ti se pare interesant, in timp. In general un lucru e interesant daca esti productiv in a-l face, si nu devine boring dupa ce faci acelasi lucru cateva luni la rand..”.

Probabil ca inceputul este cel mai greu,  prima propozitie, primul interviu, primul job. Anii de liceu s-au terminat inainte sa ne dam seama, “bac-ul l-am luat usor”, a si venit prima sesiune, apoi a 2-a ... se apropie ultima. Anii de liceu au fost cei mai frumosi iar in facultate ai toata libertatea din lume; dar ce sa intampla cand se termina? Unde dispar concertele, vacantele, meciurile de fotbal, petrecerile si zilele in care nu faci nimic?

            Sa fie oare raspunsul atat de simplu precum: “intr-un birou”? Se poate oare ca de acum incolo sa devenim niste robotei programati sa se trezeasca diminieata, sa bea o cafea in graba, in drum spre metrou sau in masina la stop (unde iar este o coada infernala), sa stea pe un scaun 8 ore (numarand fiecare minut pana ceasul va arata ora 6) dupa care sa se grabeasca din nou catre metrou/masina (iar aglomeratie, iar cozi) pentru a ajunge acasa obositi si deprimati, fara alta dorinta decat aceea de a dormi 10 ore neintrerupte, ca sa adune energia necesara pentru a o lua in ziua urmatoare de la capat?                       

            Nu, asta nu poate fi adevarat, noi nu vom ajunge in situatia asta, nu-i asa? Si totusi … trebuia sa ne gandim mai bine inainte de a alege Facultatea de Informatica, poate trebuia sa ne facem piloti de formula 1, ghizi montani sau actori de comedie.

Dar nu am facut-o, motiv pentru care inainte chiar sa implinim 21 de ani ne-am trezit la un interviu intr-o cladire pe langa Calea Mosilor. Totul merge bine (oare?), venim si la al 2-lea interviu si la al 3-lea. “Oamenii astia chiar vor sa ne angajeze”! Avem totusi putin noroc si amanam prima zi de lucru pentru 1 Martie.

Da, asa este, suntem inca in februarie. Daca zambiti ingaduitor si va spuneti ca nu am lucrat nici macar o zi si deja ne plangem, aveti dreptate. In ultimele 3 luni, cate s-au scurs de la primul interviu, ne-am temut putin de drobul de sare.

In realitate, drobul de sare nu exista, el este doar in imaginatia noastra. Viata si distractiile nu se termina odata cu facultatea. Incepe o noua etapa, in care vom avea ocazia sa ne dezvoltam, sa invatam si experimentam mereu lucruri noi. Am gresit cand ne-am imaginat in culori sumbre primul job. Trebuie mereu sa ne straduim sa ne ridicam la nivelul asteptarilor, sa fim optimisti si energici, pentru ca, de fapt, niciun final de etapa nu este o pedeapsa, ci o noua sansa de a face si mai mult (se stie doar ca orice sut in dos este un pas inainte). Si cine stie … s-ar putea chiar sa ne placa. In mod sigur asta este ceea ce ne dorim, sa ne acomodam si sa venim cu placere in fiecare dimineata.