An example of requirement change management process is as follows:

1. Log the changes.
2. Perform an impact analysis on the work products.
3. Estimate the effort needed for the change requests.
4. Reestimate the delivery schedule.
5. Perform a cumulative cost impact analysis.
6. Review the impact with senior management if thresholds are exceeded.
7. Obtain customer sign-off.
8. Rework work products.

So, you should record each change in the project documentation, on the product backlog on agile projects and the project specification in structured projects. If you do not record all changes that are made to any software piece, there is not log or evidence that were made changes to the project, and you are loosing the core project specification. Any change requires analysis of all changes that are applied to the software piece. If you do not perform analysis, you are delivering software pieces without the proper structure and logical basis, even if you are working with prototypes. And finally, all changes should be measured and estimate the effort required to complete them, without an estimation of those efforts, you will not be able to handle the change set cost, deriving in a project with a higher cost than it was measured originally. Even if you are using agile or structured methodologies, you should measure changes and manage them.

So, if you are working with project managers that are not reestimating the delivery schedule with requirement changes, you are really wasting your time on that company. You can find about this topic on any modern project management book, and you will agree with the idea that a requirement change implies a change in the delivery schedule.

If you think in software pieces like products or physical products, for example like building houses, if you have some UML diagrams, like class diagrams and sequence diagrams, which are specifying how the application should work, if you receive changes over those diagrams and specifications, is the same thing as changing a house plane, you need to rebuild and refactor everything, and it has a very high cost. The same applies to those applications implementing work flows, if they are implemented using precarious if statements, instead of using state machines, any change to the work flow will lead you very hard changes on the code. So you should measure and control each change, so you must do management.

Copyright © 2012 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2012. | Permalink | No comment
Post tags:

Each bug type has its own format — I think — and they should provide the proper information to the development team to be corrected. So, those reports that are saying «does not works», simply should be avoided. The less information that you provide, the less clear is the bug report.

functionality bugs

They are related to those bugs that do not produce error screens, core dumps, or application crashes. They are only related to those bugs that allows the application to work, but they have the wrong implementation, disallowing the application to work properly. So, the information that should be supplied on those reports should be as follows.

1. Bug Title, not more than 250 chars describing the bug.
2. Bug Description, an extended explanation of the bug.
3. Location, where it is produced (screen or URL).
4. Bug Solution, how it should be solved (not technically speaking, but with a proposed solution).
5. Steps to Reproduce, how you should reproduce the bug in your environment.
6. Related Media, screenshots, videos, audio and related stuff that could allow the developer to have a clear idea about the bug.

As they at a very high level, they do not require technical details. So, this kind of bugs should be very well described to eliminate them. Also if you can attach a flowchart or similar diagram to let the developer to know how it should be fixed, or any diagram allowing a good understanding of the bug, it is a very good approach on how to fix it.

programming bugs

Well, if you the code has a bug, probably it will produce a visible error, that shall be reported and fixed quickly. So, you must provide enough information about them. When you are reporting bugs, you should have in mind at least three points: «how happens?», «when happens?» and «where happens?». That should be enough to allow the developer to solve the fourth point which is «what happens?». So, you should provide the following information.

1. Bug Title, not more than 250 chars describing the bug.
2. Bug Description, an extended explanation of the bug.
3. Location, where it is produced (screen or URL).
4. Backtrace & Technical Error, what is displayed on the screen or logs with a backtrace or similar kind of technical report.
5. Bug Solution, how it should be solved (not technically speaking, but with a proposed solution).
6. Steps to Reproduce, how you should reproduce the bug in your environment.
7. Related Media, screenshots, videos, audio and related stuff that could allow the developer to have a clear idea about the bug.

technical bugs

It is related mainly to configuration issues, for example date formats and similar ones. And it should contain the same information as the programming bug, but it is different because it does not cause application crashes and stops the application work. But it is a bug and it should be solved. So, probably the priority of them is lesser than programming bugs. Just remember to always provide enough information to classify and reach the bug on testing.

Copyright © 2011 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2011. | Permalink | 2 comments
Post tags:

programming paradigm

Well, seems that a large amount of users are preferring the well known object oriented paradigm. That means that they prefer to code objects and large statement sequences to solve small problems. A small group prefers other multi-paradigm languages, like Python, Ruby and JavaScript. So, the 67.07% prefers the object oriented paradigm and the 21.95% prefers multi-paradigm languages, the remaining 10.97% prefers functional and procedural paradigms. The problem is the fact that object oriented languages are loosing its purity and are becoming multi-paradigm languages. For example Java has included anonymous functions, like C Sharp does. Also you must remember that Ruby, Python and JavaScript have defined functions as first class inhabitants, so they are multi-paradigm languages.

Preferred Programming Paradigm

So, I assume that the big percentage that likes object oriented over multi-paradigm languages, do not wants to use anonymous functions and closures on his code, among other features that makes programming more friendly. Is hard to understand that, but I can deal with it. Seems they are very purists. But also you must remember that there are various frameworks using the multi-paradigm approach, rather than being purely object oriented, like jQuery, which uses closures and higher-order functions as its main abstraction. On the statically-typed languages like Java and C Sharp, we have some multi-paradigm approaches too, like LinQ.

type system

Seems that everyone loves the dynamic typing system. A system that allows you to add integers and numeric strings getting an integer as result seems to be cool for many people. Personally, I prefer static typing and strong static typing, because they allow me to introduce less bugs than dynamic typing. So, languages like Ruby, Python and PHP have a preferred type system than Java, C and C++, where both of them have a static typing system, and C Sharp now has a hybrid system, where you can change the type dynamically using var. Static typing allows to cast variables, strong static typing not.

Preferred Type System

For example Haskell provides a strong static-typing system, and due to its functional paradigm and its variable immutability, you cannot cast variables, and rather than type casting you should do explicit type conversion using its core functional abstraction. Remember that functional languages usually are state-less languages, so there you cannot change the variables along the execution, and they cannot handle any type casting operation. That is why there are many lift operations in some abstractions like Monoids, where you must use a lifting function on the map() operation. So, 57.14% preferring a dynamic type system is a large amount of developers I think.

compilation type

I am figuring that people prefers much more native compilation rather other types of compilation. For example the sensation of having slow performance on Java applications because they have a heavy disc usage while they are loading libraries for its virtual machine. So, they prefer to compile natively using machine byte-code rather than using virtual machine byte-code. But the difference is not too much between have the option to compile the virtual machine byte-code as native byte-code.

Preferred Compilation

So, having the optional compilation with all options seems to be cool too. For example languages driven by LLVM will probably allow both VM and native byte-code compilation. An example is Haskell, where you can use in-memory compilation — which is done by the command line interpreter and its REPL shell — and its LLVM byte-code compilation, which is commonly used to distribute its binaries. Also, seems that .NET driven applications can be compiled using native byte-code too. I hope that Java will have a similar option in the future, that would be really nice. Also Python provides on-memory compilation on its REPL.

syntax sugar

Well, seems that predefined operator interfaces like Python has, is the preferred language feature, without custom operator like C++ and Haskell have. For example if you want to overload the + operator in your class, you should implement the __add__() method in your class, without having the option to create a new custom operator as +++, that can be defined with a very friendly syntax in both C++ and Haskell. The next group prefers language defined shortcuts, instead of operator overloading and custom operator creation.

Preferred Syntax Sugar

The problem of those languages without custom operator and operator overloading, is the fact that they cannot be used to define combinatorial operations with a friendly syntax, so you are forced to use method and function calls instead of doing combinatorial operations. Sometimes using combinators is cool, and you can make wonderful stuff using them, like deriving the Y-Combinator to implement recursion without using recursive calls — but this is more like an academic example rather than practical one. At least Python allows you to define your own operator, allowing the implementation of your own combinatorial operations.

indentation

I am very glad to see that a large number of developers prefers to being strict as Python requests, rather than getting freedom about the language indentation. Python requests you that you must indent the code properly, using equal distance between the gap and the code on each block, so if you have a wrong indentation, the code will not compile. Being strict on indentation is cool I think.

Preferred Indentation

Others prefers to indent the code under normative, which is not bad, but can lead to indentation errors, but it is fine. I do not understand people that wants to code without normative, where disallows programmers to create more legible code. So, probably they prefer languages where there are not style checkers to use, like PHP. Is very nice to see that most programmers prefers strictness regarding well indented code and ordered code, making it more legible and more friendly to read.

naming normative

So, a big number of developers prefers to use the camel case naming convention, seems to be more legible than others. But some languages like Python have defined capitalized case for classes and underscores for methods. Otherwise, languages like PHP do not have well meet coding standards, and seems that every project has its own naming convention.

Preferred Normative

This is probably a big problem on code legibility, but not at all. Is betters to have people that agree with standard usage rather than avoiding them. Well, camelCase is widely used, I agree with it, but I do not have any problem on switching between coding conventions between my projects and the languages that I use. You should ensure that your projects will use a well defined naming convention, so you can introduce more easily new developers in your team.

community

Is nice to see that most developers agree with the idea of having open communities rather than close ones. That allows permanent contributions to the language development, allowing the creation of user groups, mailing lists and help forums. That increases the language usage as much as I know. As examples of large communities you have the PHP community, with only disadvantage of allowing multiple standards on code indentation and naming conventions, making PHP programming less attractive than other languages.

Preferred Community

Finally, I agree with the idea of having an open community with clear rules, rather than complete freedom. This ensures certain quality standards around the language and the people that participates on the development process.

language of choice

Finally, the language that most people prefers — at least on those that have answered the poll — is Python, among other options like Java and Ruby. So, it seems to consistent with previous answers on the poll. Also seems that PHP is loosing its popularity between developers, because it had less than 10% as preferred language. So, most people is preferring Python, Java and Ruby, very close to the 20%.

Language of Choice

So, I can conclude an ideal language should be like Python on its indentation strictness and syntax sugar, but using camelCase and having a community like PHP, running over a virtual machine that allows native compilation. The closest language that I know running under those conditions is Jython, which is Python running over the JVM and JRuby on the Ruby side, where both have a dynamic type system — which is treated as static type system in background. I hope that you will enjoy the poll results as me.

Copyright © 2011 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2011. | Permalink | 2 comments
Post tags:

The typical behaviour is about placing a job position ad somewhere in the network or newspapers. Then those project managers receive the resume of various contractors, and they choose the one that is looking with both experience and cheaper price. Those managers will prefer the developer B, who names the cool technology based on the language L various times on its resume and has worked on big companies, rather than selecting the developer A, who has participation on developing the language L, who has a verified github account and well commented commits and who has made talks related to the language L, but he did not place the cool technology various times on its resume and have not worked on big companies. A bad decision I think.

As result of his decision, the developer or contractor B will charge few payments to the manager leaving the project half done, with various bugs. Then the manager realises that he must contract the developer A, because he just noticed that he can fix the project, and he will probably not find another available developer that is good enough to finish the project.

The developer A with much more experience will not receive the payment as he deserves, getting bored quickly. Casually, PHP and .NET technologies are overfilled of those types of projects. I have received many times project proposals, I have sent the project bid, and then I got back the denial to build that project due to the cost, but with the non surprising notice that the same manager few weeks or months late is contacting me again to fix the project that the cheaper developer was not able to complete, with a very tight schedule due to the previous developer failures. Among the lack of ethics and respect, he does not want to pay the real cost of the project. So, I will not handle those «please fix my project» proposals any more. If you will not be doing the project with me from the start, do not contact me. I am really bored of dirty, messy and buggy code generated on that kind of projects.

So, you should request assistance each time you will hire a contractor that will code for you, assistance on filtering resumes and selecting resumes if you lack the proper knowledge to understand a technical resume. Just to choose the right contractor. Take care when you are reading a resume. Try to request sample source code, ask if the contractor is good enough to write articles — for example in a blog — or magazines, watch he has some recommendations and similar stuff, but overall, request assistance to evaluate his resume if it is very technical for you.

Copyright © 2011 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2011. | Permalink | No comment
Post tags:

Unit tests are made to check that functionalities and source code is working. So, each time you develop a new functionality, you should add unit tests, but only once the requirements are defined. If you make hard changes, like changing the domain model, you will probably lost all your unit tests. Just as an example of the impact that has a change of that magnitude.

So, doing evolutionary unit tests with agile methodologies, requires that the backlog is successfully complete on each sprint to allow you to create the proper unit test, for both functionalities and low level functions when they require special algorithms. A well defined requirement should be covered by passing tests that are covering both the correct system operation and possible failures, like introducing invalid input. That is evolutionary unit testing, so you can prove that your code is working. Without well defined requirements you cannot add unit tests.

Unit tests are not only about working feature, you should add all possible failures to ensure the application robustness and for the application health. That is not only a «must do» in unit testing, it also covers the system safety. For example if your system requires a numeric string input to be parsed as integer type, you should ensure that it will work fine if it retrieves a corrupted string without numeric characters, so you should add unit tests covering that case, and design a strategy on that possible failure. But you cannot add a good unit test without a well defined requirement.

So, with a well defined backlog and requirements, you will be able to add consistent unit tests according to that functionalities, rather than adding individual tests without a precise target to cover. Once the unit tests meets the requirement and the functionality is fully working, you can add automated functional tests to cover user side tests, using for example Selenium IDE to work with them, where a functional test is made to tests functionalities, rather than components like does unit tests.

Copyright © 2011 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2011. | Permalink | No comment
Post tags: