Tuesday, December 11, 2012

As a I would like to so that

A user-story breakdown is as follows:
  • As a <user> I would like to <do some function> so that <reason/value>
A common mistake when writing user-stories is that in the section where we specify the <user>, the author of the story specifies the owner/requester of the change instead of a system user. 

A user story is meant to bridge the business and the system/code. This means that the <user> has to be a tangible entity understood from a business perspective as well as from a development stand point.

When a business member reads "As a <user>", he/she may understand this as the "person who is using the system", while the developer is reading it as "the user with type T with permission XYZ". Both are correct. Both have a different view of what a <user> is, but most importantly both are talking about the same user and again.... both are correct!

Wednesday, September 5, 2012

I Love simple software.

So I was bored today and decided to play around with factorials on Google (Yes, don't make fun. Factorials are exciting, They are the epitome of exclamation marks! ) and to my surprise, a calculator now loads when you enter a formula on the search bar. Try entering "5!".

I know I know, It's just a calculator, but the exciting thing about all this is the simplicity of the idea and how such a simple idea can be so functional, practical, and powerful.

This brings me to software UI, Functionality, behavioral and problem solving simplicity in general. I recall one of my professors in university always saying "The simplest solution is probably the correct one".  How true this is back then when working on my assignment as it is today working on company projects. I rely on this statement in my day to day work, and so far, it never failed me. 

Expanding this further to the outside world, some of the most successful software ever built, some comparatively speaking, are focused on being simple for end users and simple for the developers to maintain.

In my opinion, some of the simplest software interfaces/tools/systems that I can think of are:
  • I give you: Microsoft Calculator - Simple interface/Tool- If you ever owned a Windows OS, even the 1st BETA version, you have used it. If you didn't, odds are that you did without you realizing it. If you still say you haven't used it, I say you're a liar. If you are a holy person and don't lie, I say get out of your cocoon, open Run > Calc and play around with it. The idea behind it is simple to the point where you know how to use it without thinking about it. I cannot talk about how this was implemented, but given that it has been around for ages without it being changed in windows 95 to XP, to me, this implies that there is some form of simplicity, extensibility, and maintainability in the design. 
  • Google search boxSimple interface - A single magical text field; enter what you need, and a result set is displayed. Again, the idea behind the usage is simple to the point where you know how to use it without thinking about it. If you ever notice Google applications in general, they revolve around being as simple, and as least "UI crowded" as possible. What does this imply? Simple UI, Simple Forms, and proper division/inheritance/decoupling of the code in the background.
  • The LIKE link/button on social media sites - Simple interface/system - So simple to the users, with immense power to the companies who store and analyze what is liked and what is not. Many of the advisement you are bombarded with these days are a result of your 'likes'.
  • The US air-force F22 Fighter jet - Simple interface, comparatively speaking -  ( please don't quote me on this) I was looking online on WIKI and it was explained that the interface for the jet was so functional and simple compared to older aircrafts, that anyone with basic military fighter jet training can fly it. ( Again, I have no references to back this up anywhere, so if this is false, then it's false)
  • Last but not least, ScrumQueue. - Simple interfaces/tool/systems - I was so fed up with how complex project management software in the world out there to the point where I literary created one myself with simplicity in mind. I use it for any project I work on. The objective: manage my backlog of items with a simple status and history logging. I don't need fancy colors/etc. I use it and never looked back. Of course, I am always tinkering with it to advance it with new features, but always with simplicity in mind. This is my salesman pitch :-)
IMPORTANT: Simplicity does not mean Lack of Progress, 
It means Smart Progress

And here is a screen shot of the magical calculator that enlightened me to write the above.


Sunday, August 19, 2012

SAMBA Flight School© Updated !!!

Well, I finally got a chance to update the SAMBA Flight School©  page today with screen shots and a brief description of the applications. To all the Flight Schools out there: THIS IS FREE !!!!!!!!!

Tuesday, June 19, 2012

Google Master Search terms and research

You can find some helpful keywords to become a good master searcher via the following:
http://majedlinecode.blogspot.ca/2012/06/google-master-search-terms.html

If you plan to do research, then research articles on sites such as http://www.jstor.org  or http://scholar.google.com/

Remember
 for research, search engines will direct you to sources, but they are not the sources. Try looking through the references in Wiki for example as another research source for a specific topic.

Tuesday, June 5, 2012

Floating-point errors. Computers cannot precisely represent all real numbers. Here is an example.

"Floating-point numbers cannot precisely represent all real numbers, and that floating-point operations cannot precisely represent true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers." (From Wiki)

Today I experienced just that. On a MSSQL query. I must say, it was a very exciting bug to find. (and a bad one). Here is the Example:

select(convert(float,189)-convert(float,128.87)-convert(float,60.15))

-- This yields: 7.105427357601E-15 Let's call the result "MyCalcValue"

Now imagine you are dealing with a financial transaction. Picture 187 as being the total amount to be paid, and there were two payments made to cover for the amount due. If you have the code in SQL Stored Procedure or SQL Function  (which shouldn't be in the 1st place) and if you are doing a comparison saying something like: IF (MyCalcValue > 0.00) THEN print "Amount due" ELSE print "Amount paid" Then you would run into trouble. Your calculation will yield a positive value, and there will always be an amount due. In MSSQL, fortunately, you can deal with this problem by using  money.

select(convert(money,189)-convert(money,128.87)-convert(money,60.15))

-- This yields: 0.00 
I'll be reviewing my university notes and hopefully post more about this. Exciting stuff when theory comes into practice.


Monday, June 4, 2012

Support Blackberry in the interest of security and productivity.

Support Blackberry in the interest of security and productivity. The office needs work tools, not fun stuff!!!!

Can you tell I'm a Blackberry fan :)
Majed A
http://majedline.blogspot.com

Wednesday, May 9, 2012

Wednesday, May 2, 2012

Best Developer and Best QA.

Today I had a thought, how can you define 'the best' developer and QA?
( Any rebuttals are welcome )

  • Developer- one who trusts the work of his developer colleague, but not the QA's work.
  • QA - one who trusts the work of his QA colleague, but not the developer's work.
So here are the arguments:

As a developer, I rely on the fact that my classes, functions, methods, etc.. use my colleague's libraries, classes, properties, functions etc.... So I have to trust my colleague in doing the necessary work to help me and vica-versa. If I don't, I would end up doing the work all by myself and duplicating what he/she did, and we all know that this is never good idea as it will cause more problems in the long run ( and the owners won't be happy about the wasted money)

Now in regard to the fellow QAs; if I the developer don't trust them then that means I have to test my work to ensure things are good. And by test, I want to do all that I could do to not get bugs from the QAs as much as possible in a legit way ( No cheating here and doing patch work to hide bugs!!). And we all know that tested code before reaching the QAs are most successful. Even if you ignore the fact that the developer implemented something in the most convoluted way, if it works.. It works! ( Do I sound like a PM now or what ).

To be fair, I'll add one more rule regarding the above; code should never be more than an order magnitude O(N^2)]. Otherwise in the long run, it'll take forever doing anything.

As a QA, the same argument applies. I as a QA cannot do all the testing. I have to rely on my QA colleague to test all areas and functionality that I would use in my areas and vica-versa. Otherwise I won't be sleeping the night doing all the work myself.

In regards to not trusting the developer, well if I do, then why bother doing the work? If I don't I will do my best to find a bug. And by bug, I mean a legit bug, not 'this is a pink background, not off pink as required'.

So how did I come to this conclusion you ask? Experience as all the above and PM/Scrummaster! I have seen the most experienced Devs. come up with some amazingly designed untested code. It ended up being littered with bugs and took twice as long to release. On the other hand, an average dev provided the QAs with tested code, it took half the time in testing, was ready ahead of schedule and caused the QAs to focus on hard bugs. The same goes for QAs. Those who trusted the work of the developers, ended up sleeping on the job (literally). Those who didn't, found some amazing loopholes and bugs no one would have thought off.

You combine both together, an 'untrusting' developer with an 'untrusting' QA, and you will end up with production ready code in no time.

Majed A
http://majedline.blogspot.com

Wednesday, April 18, 2012

No Silver Bullets to Software

Good read below.

'I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.'

Ref: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Majed A
http://majedline.blogspot.com

Monday, April 2, 2012

Agile is not a project management methodology, it is a software development methodology.

Agile is not a project management methodology, it is a software development methodology. It is an approach to developing software in a team environment. You can still have and maintain many of the metrics for a project as well as maintaining scrum (or whatever flavour of agile you use).

To all PMs out there, don't confuse the two!!!
Majed A
http://majedline.blogspot.com

Wednesday, March 14, 2012

Industry problems - no trust

One of my previous managers in the past stated that Software development is a communication problem. Today, I recall this and I could not agree more.
In my experience, the biggest obstacle to this is the lack of trust (don't confuse this with competition). You solve that on a team, department and organizational level, there is no question your business will grow with success..( And you deserve some sort of award for that matter... )

http://majedline.blogspot.com

Tuesday, March 13, 2012

Support in an agile team.

Q. How does an agile team help support products at the same time working on system changes?
A. Adjust your team capacity to accommodate the support work. Anticipate the work and assume it will be there.
Example: in an iteration, we can handle 50 points. We know we are always behind 5 points every iteration as a result of support. So in the iteration planning, set 5 pts for support. This way you would estimate for 45 points.
Note that, the owners might not like this, so make sure you have the stats and metrics to backup your claim about the 5 points!

Saturday, February 25, 2012

Agile Adoption must come from the top down in a business

Agile software development requires a mind-shift in how to approach software solutions in any business. It must be understood by all and accepted by everyone in an organization. This is the hardest part of any organization which would like to adopt agile/scrum.

Any mind shift must come from top down. It must be understood by the executive levels so that it trickles down and can be properly adopted by everyone in the business.

Throughout my experiences, I found out that many organizations keep trying to adopt agile for a very long time. In 2009, I researched one company in Canada that has been trying to adopt agile for over 10 years. The problem as to why it took (taking) too long is that the mind-shift was not coming from top down. It was being "conveyed and suggested" to the business from the team out. In other words, this team had to convince everyone in the organization that this is a good thing. You can picture the obstacles and politics that will come along with this.

 In 2010, there is a Toronto based company that recognized it was falling behind the other competitors and it was narrowed down to the fact that competitors are applying agile while they did not. The execs in this company decided to apply agile as a solution to meeting up with the business needs. This came from top down. The organization adopted and promoted agile within 1.5 years. Execs understood the need for change and are providing the right tools and structural changes to accommodate for this adoption.

In Summary, If you are a team member that think agile needs to be adopted. then convince the main exec/president/ceo/... etc, and the company will follow through with the adoption.

Thursday, February 23, 2012

Simple is probably right, but may not be easy!

The simplest solution is most likely the most proper solution. But the simplest solution might not be the easiest.

Does the business really know what it needs?

So we work day in and day out; when it comes to software, does the business really knows what it needs?

Throughout my experience, no. They might think they know the problem and solution, but the problem is never clear until we are dealing with the nitty-gritty details.

Picture waterfall model. Odds are you wont experience and know the answers until late in the game. You do all the analysis, which in most cases is still business focused, design, and then implementation. You will find you answer somewhere in there.... But again a bit late

Picture agile now. You brake the problem into sub problems. It is an approach to divide and conquer of a project. Answers will start popping up early on because iterations are short and once you are finished with an iteration, it's done. All questioned answered and you jump to the next problem.

Sunday, January 29, 2012

Bill C-11 could bring SOPA-like online piracy laws to Canada

Bill C-11 could bring SOPA-like online piracy laws to Canada.
Contact your local MP and voice your concern about this!!!!!!!

We need to protect the internet and some of the fundamentals data management.
Imagine

  • you buy a CD and not be allowed to copy the content to your MP3
  • you want to unlock your phone to use your current phone with another provider, or do research.
  • you getting accused of piracy without evidence, and your ISP will terminate your access just based on that.
The following link will direct you to the actual bill.. look through it and you can pick out the above plus more.
 > http://www.parl.gc.ca/HousePublications/Publication.aspx?Docid=5144516&File=9


Other References:
http://business.financialpost.com/2012/01/24/sopa-like-laws-could-be-coming-to-canada-expert-warns/
http://dearthey.com/2012/01/26/a-copyright-quickie-canada-is-about-to-pass-sopas-evil-little-brother-politely/

Monday, January 16, 2012

Be the best you can be and diversify your skill set.

- To be the best you can be as a developer, you need to be able to know how to test.

- To be the best you can be as a tester, you need to be able to know how to develop.

- To be the best you can be as a business analyst/owner, you need to be able to know how to design an application.

- To be the best you can be as a system designer/architect, you need to be able to know how to perform business analysis.

Agile brings all these aspects to the team as a unit and takes advantage of each individual's skill set; not only one skill. This will maximize each individuals ability in a project, at the same time promoting the learning of other skills to maximize their own input within the team

- Last but not least, to be the best Software System Manager, you should know all the above.

In summary, be the best you can be and diversify your skills set!!

Friday, January 13, 2012

Agile User Stories

An agile user story should not be used as a sign off document. It should be used as a negotiation tool to reach an agreement between the team and the product owner on a change

Wednesday, January 11, 2012

Simple windows java make file as batch

Simplify your life, create a 'make' file... here is one...javac, javadoc 'make' file for windows. Save it as .bat ... enjoy.
@echo off

:: NO PARAMATER PASSED. DO COMPILE AND SHOW CLASSES
IF  ANYTEXT==%1ANYTEXT GOTO COMPILE
:: otherwise do everything
IF %1 == "-all" GOTO CLEANCLASSES

:CLEANCLASSES
Echo --REMOVING ALL CLASS FILES--
del *.class

:COMPILE
Echo --COMPILING ALL JAVA FILES--
javac *.java

:: no need to do java doc. this is a compile.
IF  ANYTEXT==%1ANYTEXT GOTO SHOWCLASSES

:JAVADOC
Echo --CREATING JAVA DOCS--
javadoc -d ./Docs *.java

:SHOWCLASSES
Echo --THE FOLLOWING CLASS FILES WERE CREATED--
dir/b *.class

:: no need to do run the application. this is a compile.
IF  ANYTEXT==%1ANYTEXT GOTO END

:RUN
Echo --RUNNING NOW.....--
java MyApplication

:END
Echo --END OF MAKE. --

Thursday, January 5, 2012

NetBeans IDE 7.1 Now Available...fun fun fun... http://netbeans.org/

A new NetBeans IDE 7.1 Now Available. Say what you say about Netbeans. I still like using it. I guess I will be playing with it tonight.

http://netbeans.org/

Tuesday, January 3, 2012

The economy is one big project.

My comments below are in square brackets. I thought it would be fun to try and argue that the economy is one big project, the Feds is one big team, and us being one huge owner.

"WASHINGTON (AP) -- In a major shift, the Federal Reserve [the team in this project] will start announcing four times a year how long it plans to keep short-term interest rates at existing levels, according to minutes from its December policy meeting. [So. The economy is one giant project. Used to run on 2 iteration per year, now 4. This is a result of several giant retrospect meetings know as the G8 economic summit, among others]

The shift marks the Fed's latest effort to make its communications with the public more open and explicit. [One of the basic and essential rules in Agile is: transparency.]

The change is intended to reassure consumers and investors [the product owners, the general public] that they will be able to borrow cheaply well into the future. And some economists said it could lead to further Fed action to try to invigorate the economy. [So expect more retrospect meeting and based on those, expect constant improvement to the process]"

>>Reference of quote above<<
http://hosted.ap.org/dynamic/stories/U/US_FED_MINUTES?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT

Scrum master... "show" and "clear" the way, not "direct" the way

One problem I see more often than not is when scrum masters and PMs start directing a team rather than showing and clearing the way for the team. A team is a unit that works on a target. When PMs or SMs start directing the way, they are removing the element of self organizing, which is a key element in agile software development.

In summary, to all SMs and PMs ... Show and clear the way/path for the team to do what it needs to do.

A team can do the work :)