Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts

Thursday, August 27, 2020

[Video] Think before start coding to automate your next task

We as developers tend to automate our tasks without thinking much. Sometimes it would take more time than doing it manually. Obviously, automation gives us better accuracy but it is good if we know what is the Return on Investment Before we automate our next tasks.

Watch the video for further details.

References

https://www.youtube.com/watch?v=D80GucAAD4c

Tuesday, December 15, 2015

10 years in software industry - What I learnt?

What's this post about

As of  7 Nov 2015, I have completed 10 years in the software industry. I have started as developer support engineer and now working as application architect. Currently in my third company, working places range from Chennai, Kochi in India and New Jersey, US. Worked in products and projects. Lacks pure consulting. Technologies are mainly Microsoft, little bit of Android and HTML,JavaScript & CSS based web.

Just thought of scratching my learning and some advise to other fellow developers. These are solely my views. You may agree or disagree. Sometimes will have entirely different opinion.
  • Programming
    • Design - every programmer should create/have minimum design before typing.
      • Hardest thing in programming is naming things. Spend some time during design at least for public classes, methods etc...Private things we can change at any time to a meaningful name.
      • Do no think when coding. Do not code when thinking.
        • But these activities needs to happen in short cycles. eg: Think and design for 15mins and code for next 15 mins and commit your changes.
      • We can never build a generic generic program. If it was possible world does't had these much programmers.
      • Think about generic mechanism and patterns, if something is repeating 3 times.
      • Design API by first writing client/consumer apps. Better test from 3 different clients/scenarios before finalizing.
    • Problem solving
      • If struck on a problem for 30 mins, take a break. It will clear our bias and help to think out of the box.
      • If the above is not helping explain the situation to some one who may or may not understand software. 90% of time, during the explanation new idea will pop up in our brain. Brave people can try rubber duck debugging also.
    • Defect fixing
      • Fix code by eliminating code not by adding code.
      • More code, more defects.
      • When testing team reports a new failing combination, try to add that in unit tests when fixing.
      • There are some defects which will never get reproduced in development. But had to fix by looking/reviewing the code.
      • Always write down debugging steps, so that you can restart from where you stopped after attending call from wife or girl friend.
    • Code quality
      • There is no perfect code. After spending days to finalize one class, a new person seeing that first can suggest improvements. Need to balance to meet the release time.
      • Do not refactor for the sake of refactoring. Refactor as part of new features or defect fix. But make sure those are different commits to source control.
      • Achieving SOLID is difficult. At least make sure your functions are doing one thing and write pure functions.
      • If possible get the review done via writing unit tests.
      • During day job, often the priority goes to meeting deadlines and developer will be forced to write bad code. So develop personal projects or participate in open source projects to write perfect code where there is no deadline.
      • It is not possible to meet a deadline without any hacks. The quality should be maintained by fixing it immediately after the release. In case, its single delivery, try to fix before completion.
    • Coding practices
      • Assembly language era is over. JavaScript has got many minification utilities. So let's program for fellow developers to understand. They are going to maintain the code in future
      • There was a misunderstanding that writing unreadable, complex code will keep the job safe. But that is not true as the new generation developers are writing code way earlier than us and they are smart to take over. 
      • Keep state in one place. Make 90% of classes / code stateless.
      • Do not keep different scenarios, you thought during coding in your head. Document as test methods. Else after some months you cannot understand why you wrote.
      • Communicate what code does via proper variables,functions, classes and component(dll) names. 
      • No comments for explaining logic. This is because when next person changes the code there is no guarantee that he will update comments.
        • API documentation is fine. Eg: xml comments in .Net
    • Source control, build & deployment.
      • Commit your changes within maximum of 30 mins. If you are not able to complete something after 30 mins, go back to thinking/planning and split the tasks appropriately. First step can be creating the source folder structure / test classes and committing those.
      • Do not comment the code for using in future by uncommenting. Its there in source control. If your company is not using source control quit immediately.
  • Architecture
    • Tough task is to balance between delivery timeline and quality. Should never go to extremes.
    • 90% of the time it is not built. Its evolved.
    • Do not stop coding. If you do so your design will be just boxes to developers.
    • Spend time to validate whether code is following arch. Sometimes change arch to the way code is going.
    • Try to avoid third party libraries as much as possible because each library is adding one more dependency on your plan.
    • Have an idea/capabilities about all the known technologies at high level. Dig deep only when required.
    • Think how architecture is going to be coded, tested, deployed and maintained before finalizing. At any point a developer, tester, infrastructure or support guy may come and ask how to do something in detail.
    • Learn buzz words / technical jargon to talk to different people.
    • Communicate to different level of people in different levels of details. To a client/stakeholder a holistic approach, to business don't use technical words, to managers only about deliverables and developers only in terms of programs.
  • Project management
    • Follow the below principle in Agile
      • Get it done - Demo
      • Get it right - Put into QA
      • Get it optimized - Production and maintenance.
    • Do not plan more than one sprint.
    • Create a new branch in source control start parallel development only when its really necessary.
    • Setup a CI & CD at any cost. Manual build and installation is old story.
      • If there is no test cases, do not push to production via CD.
    • Try to get code freeze at least 1 day during the build & release days.
    • Let the developers fix the hacks during the code freeze. But do not let them check in to main branch on which the build activities are going on.
    • When every project is starting customer will have a fixed goal. Its us who should throw new ideas,improvements towards them and keep continuing the project.
    • Make sure those ideas are business related and towards cost cutting for client to improve their profit. When client's profit increases our profit will also increase.
  • As a team member
    • Ask others to review your code and accept the good parts. Even ask juniors to review your code.
    • Do not just say its not working to your technical lead without a proper description or screenshot of exception or some links saying its defect. They will think that you don't know, didn't do debugging and google.
    • If you are taking a hack or shortcut, add the details with web links as comment in source code. So that future developers will not blame you. Do not keep it in mails, because the new members into your team will not get the mails.
    • Always give suggestions to business analysts requirement documents, proposed user interfaces. Most of the time they may not be knows what are the capabilities of technology.
    • Try to be truthful to testing team. When they come up with inconsistent help them to reproduce by understanding the code.
  • Team management
    • Always have one meeting in the morning and let the team explain what went yesterday and what is the plan for today.
    • Try to reduce the time required for your team to send reports. Get the details from task/project/work item management systems such as TFS.
    • Always look at the code your team is producing. To your superiors its your code.
    • Keep quick access to release dates, number of features and defects total and pending. if you can remember some showstopper/high priority defect ids, you will be a star.
    • Do not let project depend on one person. The show must go on at any cost.
    • Give ownership of tracks/components to single person or teams for fixed time say 6 months. Rotate the members to different teams in every 6 months. But never replace everyone in track in single shot.
  • Quality in software engineering
    • If you are clicking everyday as part of testing app, try to bring automation or look for next company.
  • Enterprise Application Development
    • Most normal things won't work in enterprise. Many things done there doesn't have any common sense. But have to do to keep the project moving.
    • It is very difficult to bring a change in enterprise.
  • Self learning and carrier improvements
    • Read others code.
    • Debug for others. 
      • There are many who can type code. But very less who can debug code.
    • Try to look into third party libraries. If its unmanaged, it will be difficult but in all the other cases its possible to view the source code of third party libraries. Obfuscation makes it little difficult though.
    • Learn one new language every year
    • Read at least one technology book every year.
    • Improve searching/googling skills. A best programmer needs to be a best googler.
    • Never waste your brain memory for language syntax. Google can give it in seconds from internet. Instead free brain to keep the capabilities and think freely.
    • Do not spend much time on learning short living frameworks such as Silverlight. Instead spend time on long living concepts such as http 2. 
    • Try to create and publish reusable libraries. There are very good library management infrastructures now a days such as nuget, npm etc...At least contribute to libraries. If there is no time to fix defects report the defects in the libraries.
    • Learn how things are working end to end. From business analysis, design, coding unit testing, functional testing, business testing, build systems, continuous deployment, application support and how to work with patches.
    • If you want to become a good business analyst you should be knowing what are the developers problems and how developers interpret the requirements document. For that best way is to work as developers. Similarly if you want to be good developers, you should know how QA tests your app. Again better way is to know is to work as QA. QA may not catch all the defects but its caught in application support. So to do better testing you should be knowing how the users use the system and best place is to work in support. To me an ideal career path is Application support->QA(manual + automation)->Development->Business Analyst. Join as support and climb the ladder, If there is no chance to climb in current company change the company.
    • When to leave company
      • Evaluate your activities in your company at least once year other than performance appraisal. If you feel you got only salary in return, leave the company.
      • If you feel you are the ultimate authority of something and everybody depends on you as you are the king, leave the company, because your growth is over there.

Monday, August 12, 2013

Package principles - .net namespaces and assemblies design guidelines

How to package classes into logical groups and physical containers is always a difficult thing to decide in software engineering. Package is used as it is in Java but when it comes to .Net world, its assemblies. In .Net , the .net framework is packaged in such a way that the core classes and interfaces are packed in one assembly and framework details are in different assemblies. In such a scenario one namespace may appear in multiple assemblies. the namespace in core assembly contains base classes and interfaces where the same namespace in different or track assemblies contain implementations.

Basically we can package by feature or package by layer. In an address book application, if we follow package by feature,  add,edit, delete operation related classes ie CRUD classes will be in a single assembly and the reporting related classes will reside in different assembly. There will be 2 data access classes one for add, edit operations which falls to first assembly and another for accessing reporting related data access falls to second assembly.

Package by layer scenario ie horizontal packaging, package all the UI classes to one assembly, business logic to another assembly and data access classes to third assembly.

My recommendations on .Net assembly packaging

To be frank these are my observations on how to group classes into namespaces and how to split namespaces into assemblies. I didn't get any concrete answer from google on this topic. All were discussing about merits and demerits of different approaches and asking the developer to decide one method. So this recommendations are subject to change as my experience grows.
  • General
    • Follow the other design best practices such as SOLID, GOF patterns properly.
    • Keep in mind that software is created to change in next version.
    • Always group the classes into namespaces which are logical groups.
    • Give meaningful names to namespaces and assemblies. Reading a 100 page document about namespaces and its descriptions may not be practical when project grows more than 100 developers and 75% of them are freshers.
    • A bad assembly dependency graph is as wrong as bad code.
  • Small apps - team size below 10 and working in same location
    • Never go for multiple assemblies but must have different namespaces.
    • Separate creation of classes to factories.
    • When you feel you app is growing beyond initial estimated side create new assemblies as follows.
  •  Medium size apps - team size 10 - 30 and working in same location.
    • Aim should be less no of assemblies so that the application will be fast.
    • If you feel that you may need to support getting a different presentation technology separate the UI namespace into a different assembly
    • Keep your core classes and interfaces in single assembly.
    • Have the default implementations in different assembly where the namespace will be same for the core and its default implementation.
    • One assembly can contain multiple namespaces.
    • eg: format used below is assemblyname{namespaces}
      • AddressBookCore.dll{Joymons.AddressBook.BL,Joymons.AddressBook.DL} - contains interfaces and base classes
      • AddressBookDefault.dll{Joymons.AddressBook.BL,Joymons.AddressBook.DL} - contains concrete implemenations
      • AddressBookUI.dll{Joymons.AddressBook.UI} - implemenations and UI technology specific classes like value converter classes in WPF.
    • Have the additional implementations in different assemblies.
      • If the default data access is through SQL Server and if we want to give XML data storage support, have xml data access class in a separate assembly and change the dependency creation. AddressBookXMLData.dll{Joymons.AddressBook.DL}
  • Big applications - team size more than 30 or working from remote locations.
    • Aim should be to have maximum isolation.
    • Let each track in the application have its on core for business and data access along with  default implementations for all.
    • One assembly should contain one namespace. Name of the assembly should be same as the namespace.

Principles

Like other software engineering principles such as SOLID principle, packaging has also got principles. This will help the developers to package their classes to assemblies in a better way.

http://en.wikipedia.org/wiki/Package_Principles

Monday, December 31, 2012

What is Domain Specific Language (DSL) in software development

Wish you a very very happy new year to all.Let god make all your ventures a great success.

To me, its more like a technical new year. Last year the main plan was to get married. This year needs to improve more on application architecture side of software engineering. OK. Leave that with me.Lets get into the topic.

It took roughly 2 years to realize that we are using DSL in our project. I don’t know, why I didn't realize it in the first 2 years of project in which I was fixing DSL issues and adding more features to that. Reasons may be
  • In the first 2 years I was / had to concentrating more on the deliverable and the technical (WPF,Silverlight,WCF,Linq etc…) aspects of project rather than its logical architecture design and now I am more focused on Architecture.
  • The trainers (we had few in the beginning) didn’t tell us that we are using DSL in the project. Or nobody thought of the word DSL even though it is using in the project. (I had seen people using Singleton pattern without knowing the technical term ‘Singleton’)
  • There are 2 types of developers in the project. I would say application creators. One group is hard core .Net developers who work on the framework using VB.Net and other team uses a tool to create business screens ,its validation and the business flow.If I spent some time on thinking what is the difference between these 2 groups, I would have realized that we are using DSL in the project.
Its all fine.Now lets see what is DSL in programming ? According to Martin Fowler “DSL is a language for solving a specific problem rather than general purpose language which can aim at any problem.It’s presence is there from the beginning of computing”.The examples are SQL - which is aimed to manipulate the data storage domain, Excel formulae – Aimed to mathematical domain, CSS etc…More details on wiki

Are we using DSL in our day to day projects?

Yes of course .All of us uses DSL in our daily programming. Just think about the below scenarios and confirm yourself that you are using DSLs.
  • The framework you are created to solve the problems in your domain. The track components call the framework to fulfill business need.
  • The business layer methods you are writing to meet specific business requirement.
  • The configuration sections which are specific for business domain.
All the above scenarios are aiming to a particular domain and it’s execution sequence can be altered or configured. A language doesn’t needs to be with line numbers such as VB or enclosed in curly braces like C family languages. “Language is a medium to communicate”. By changing a configuration entry you are talking to the computer.Isn’t it?

Importance of DSL in Application development

Before we see what is the importance of DSL we should know what is special in software development which is not in other engineering branches.

Software development v/s other Engineering_disciplines

Its simple. As everybody knows the major difference is ‘constant requirement changes’. A ship construction or bridge plan will not change, if its on half way. But the software does. Can we say no to those changes? Never. Because if we say no, the project will go to another vendor and we had to look for another job. Can we collect all the requirements from the users and document the same before we start development? 80% of requirements we can collect.But the chance to collect 80% requirement is only 50%. We cannot blame anybody as the users don’t know what they want from software or they don’t know what software can do to make their life easier because they are not familiar with computerized system of their work.

If we take a civil engineering graduate, he learns how to construct a bridge in the class room and the same can be applied in real time when he works for a company project. I agree that there can be very slight variation. But majority are same. But take a look at software engineering graduate. He learns how to find out factorial of a given number during college days and he is assigned to create a site which needs to serve 1000hits/second. This is the case in almost all Indian institutions. No idea about foreign institutions.

The same applies to the business cases as well. The business of civil engineering will be same always or atleast engineer is familiar with the terms. But in case of software its is different. He needs to solve the issues of accounting, auditing or insurance and make their life easier without any prior knowledge in the business domains. Yes there are business analysts who are supposed to bridge the gap. But I don’t know how far they are good in bridging. May be I have never seen a real BA. All the BAs I have seen in may programming life are just requirement writers who write down requirements from users. They are not requirement creators. I strongly believe that only requirement creating BAs can bridge the gap between original domain expert users and pure programmers.

How to tackle the requirement change scenario in development

Can we solve all the above said issues using a magic word DSL? No.We can solve the first one and partially the last one. The solution to second problem is with institutions changing their course structure and how interested the student in knowing about industrial software development. Ok let’s concentrate on how to solve the first and last problems using DSL.

Solution – Convert your software users to programmers.

This sounds crazy.Are they going to write C# code?
No.They are going to write DSL programs

Is it practical ?
Yes. It is and we can see so many examples around. By introducing formulae and macros Microsoft excel made so many programmers. By writing cell formulae and macros aren’t the accountants and other general people became programmers? Yes they are.

May I go to users and tell them you need to learn programing?
It depends based on the level of your clients. In most of the scenarios you cannot tell them that they need to program. You need to use the words customization, configuration etc…When client reaches a mature state you may tell that there is a DSL which they can use to modify the application.

So what is the magic : Whenever you had to create / design software, model a domain language and program using it. Thanks to my former colleague Praseed Pai for the sentence.

Example - DSL in salary calculation scenario

Lets look at a real time scenario for a normal developer other than taking scenarios like excel macro .
First we need to see, how it is working without DSL. You first met the customer who is located in Kochi .He told the formulae to calculate the salary according to the on going process / circumstances.  And the formulae is

Salary=Basic+HRA+DA (It’s a small company .So no PF and other factors)

You created the software in C#.Net and the technology used is windows forms . All went well and got a good payment.

After some months Kochi became a metro and your client needs to add one more component into the salary called “Metro allowance”. Client again approached you to modify the software to add the new salary component. You modified the software and got payment for that too. Client was able to reduce (I don’t want to use the word fired) work load of 2 people in the administration department after introducing your software so that they were able to concentrate on growth aspects of company and it grown to a bigger size.
The next change came when they grew. In India if the number of employees is greater than 20, (don’t know the exact number) companies needs to give Provident fund (PF) to the employees. They approached again and this time the change is little more complicated. PF needs employer and employee contribution which leads to calculation of gross salary, deduction and net salary.

From here story can be diverted in 2 ways. You charged more by saying that, we introduced a configurable salary calculation technique so that you can enter the formulae in a particular text area and the system will calculate based on that. For example in the formulae you can refer the Basic pay using _BASIC_ . Obviously client became happy and as they are growing, they decided to create a web site and gave the contract to you. Your client is growing and also you. You will be contacted someday by other companies to purchase the same software. There is no best advertisement than your customer’s.

The other kind of the story can be like this. You charged same or little more and delivered the support for PF. Client is satisfied with the change. But they started thinking, how their competitors and other companies calculate salary. One day they will hear from others that “you know one thing we are using a salary calculation software which is configurable .There is no need to call software guys for formulae changes”. Obviously next time client will purchase that software or ask you to convert existing one in a configurable way. If you say no, that is the end. Your client will grow definitely but without you.

How was the configurable salary calculation happened? Its nothing but a DSL. You modeled / created it knowingly or unknowingly. _BASIC_ is part of that language.

Can I get a sample which uses DSL in C#

Its all good. Theories are always good to listen or sleep. How can I use this in real time as a .Net programmer ? What are the technologies I need to learn? In what language I can write DSLs? Any example ? Am I supposed to create a language and its parser, compiler etc…!!! It seems people are not suggesting that as it involves more effort.  Also when I googled people were suggesting to embed Lua, use Antlr to create parsers,define xml schema to write DSL and .net code to evaluate xml etc…How to pass my domain objects to the DSL code? How to execute the DSL?

Hopefully you can expect a post which answer the same next week same day.With the salary calculation sample of course.