Software craftmanship

Software Craftmanship

So, first things first, today's song will be "Goodbye my lover" by James Blunt

Enjoy

Today I will talk about the podcast titled "Software Craftmanship" with Bob Martin.
Bob Martin defines software craftmanship as sort of an improvement on agile software development, he talks about the need for architects to code so they feel and understand the methodologies programmers use to code.
Software Craftmanship is a mixture of agile coding, pair programming, driven development, doing well crafted software, focusing on the code instead of the design. He talkes about some ideas that seems to talk about refactoring, and leaving a cleaner code each time we modify it.

I think software craftmanship is a great approach to software development, since it defines some great ideas, as everyone working at some point on coding, since coding easily evolves, I agree with Bob Martin that if architects don't code then their ideas will be more difficult to code. I like a lot the idea of collaboration and people working together instead of coding alone, another think I think is very important is that developers have to collaborate with their clients, understanding the requirements by approaching to the client so they can produce better software.

I like a lot of agile development disciplines, since they focus on what I think is the more important aspect of software development, the coding. I think a lot of methodologies focus a lot on design and sofisticated tools (those awful CASE tools). That look nice on paper but almost always end up becoming more of an obstacle than a tool

Of course, as in everything, there is a tradeoff, but it may be appropriate to most software solutions, so maybe the key is to be flexible on choosing the best discipline for a specific project, there may be some solutions where a waterfall approach may be the best. But for most solutions, an agile discipline or an evolutionary approach may work perfectly.


With software methodologies it happens the same as with choosing the best programming language, there are no wrong approaches, you just have to choose what is best for you. So it is very importante that you know a bit about all of them, to understand each methodology's weaknesses and strengths.


I've said it many times, but in software development everything is a tradeoff, so you have to be flexible and choose what works best for you.

Wololo.

Is Design Dead?

It's been some time since my last entry (mostly because stress related problems due to exam)

So, today I will be writing about design on extreme programming and discussing Martin Fowler's article "Is Design Dead?".

First things first, today's song will be "Lost on the way home" from Chromeo, no special reason though.

There was a time where software wasn't so volatile in terms of requirements, you could gather all the requirements, then take your time to design some solution that would fit the problem perfectly, program it and deploy it, thus leading to this mythical being called "The architect". Things were much more simple than now, where everything changes very quickly, if you design based on the requirements until you've made up a perfect design, most likely the project requirements would have changed by that point, at all times you have to avoid rework and bugs, because one rule still applies now, as time passes, the cost of changing software stuff grows exponentially.

That is where agile software development comes in, a series of techniques designed to make software building in chaotic enviroments easier. One of it's most famous focus being Extreme Programming.

Extreme programming is a bit controversial, mainly because it ignores almost completely all "serious" techniques. It focuses mostly on having functional, running software as early as possible. Skipping investing time on heavy requirements engineering and design.

XP on requirements:
Since requirements change very quickly, you don't need to waste much time knowing all the requirements, instead, know the most important, basic requirements and start designing on that.

XP on design:
Design the most flexible, easiest, simple possible. Don't rely on diagrams, they are a waste of time because they are hard to keep updated, the most easiest way of design is clean code.

XP on coding:
Start coding quickly, don't code anything you think you're going to need in the near future, instead focus on the things you need to code now. After you coded and tested everything, refactor.

XP on refactoring:
Refactoring maybe the angular stone on XP, it is the main thing that keeps an XP project clean.
Refactoring can be summarized as: once you have functional code, clean it up so you get understandable, simple code.

Since XP relies on the fact that on some point, things are going to change the previous steps apply to the project on stages (stories).
Once you made functional code, you get to know which stuff is missing (at least on a very near future) so you get requirements for that functionality, design, code, test, refactor, test.

So, as the title asked, is design dead?
I agree with the author that design isn't dead, not at all, no matter what new technique is invented, you will always need some kind of design to make a software project maintainable and understandable. However, since everything is more volatile on software development than it used to be before, design has evolved to some more simple, fast, clean way of design.

Who needs an architect?

Today I will discuss the article "Who needs an architect?" by Martin Fowler.

Today's song will be "E.V.A" by Public Service Broadcasting, no special reason though.

The article talks about the definition of "software architect", the author explains how architecture is a term created to make software design sound more complex than it actually is and with a lot of Matrix references he states that architecture is just a social convention to describe what most developers think as "a high level representation of a system". Then he states that there are two kinds of software architects, the Architectus Reloadus (yes, Matrix reference here) which is most like The Architect from Matrix Reloaded, a kind of developer which has to take every decision regarding the system design, which creates a bottleneck and adds complexity to the system, and then there is the  Architectus Oryzus, which is more like a guide to the overall system development, and I think Fowler makes a bold statement when he says "the architect's value is inversely proportional to the number of decisions he or she makes", because if the architect makes few decisions then he isn't needed (the main idea of the article), however, Fowler also states that an architect decides things that shouln't change in the system, and since software isn't bounded by laws of physics as traditional architecture, then you could, in theory, build systems that are bound to change.

It all sounds very neat, and if that could be true, then Fowler has a point, there would be no need of an architect, however, I think in real software projects you need someone to lead how the system should be developed, and since every software developer knows that every piece of software we build will need to evolve sometime software projects can become a real mess very easy. The most simple system can become really complex if the developers don't have a blueprint to guide them. Lots of duplication, unneeded components and other components doing stuff that they shouldn't do. That is where the architect comes important, by designing a system he creates a blueprint which will guide the whole development, a good architect determines by his experience which things should be done bound to change and which things don't, archieving the middle ground between complexity, ease of change and maintainability.

Software Architecture

Hello everyone, today I will be talking about the article "Software Architecture" from the book "Code Draft" by Pete Goodliffe.

As in previous blogs, I will encourage you to hear a song while reading this, as I write this entries I hear music to get my inspiration flowing, so this week's song will be "The Architect" by "O.A.R", and I find it very bold how it the intro mixes a rock guitar intro with some caribbean-like trumpets, I hope you like it.

So, what is software architecture?
I found it hard the first time I heard the term to believe it, I couldn't quite understand how software would relate to architecture in any way, I remember it was my first week at work and we had a meeting to discuss some projects, I was talking with other programmers when this guy appeared in a suit and everyone just shup up and stood there, waiting for him to say something, he started talking about some very obscure things about Java and how he thought it was important for us to know, after that the meeting went pretty casual. After the meeting my friends told me about this god-like figure around the company, "The architect" was his official name around the office, he was in every project, and in none, it was very misterious to me what he did in the office, but everyone respected him, and so did I (monkey see, monkey do was one of the most useful things I learned at my first weeks on the job).

Then one day, a new project popped out, and some programmers (including myself) were asked to attend to a meeting to discuss the project development and architecture (then things strarted to become clearer). We were working on the project design and the architect just stood there in front of the whiteboard thinking, then all of a sudden, he crossed some modules we have drawn on the whiteboard and started talking about how we could skip some of them by integrating them to other modules (and some other obscure things I don't remember), and then it happened, he had simplified our original design to just five modules that contained the logic behind the whole project. He explained us how it would work and everything made sense, I had finally understood why he was the architect and what did he do that was so valuable, his sense of programming was pure, elegant, and practical.

The chapter talks about sofware architecture and how it is useful to design the project before getting to programming to avoid some nasty things during development, basically, the role of the architect is to design a software solution the most efficient, simple, way. So the project goes on with minimal setbacks, getting the most out of every trade-off.

From no-design code to client-server architectures, layered architectures or modular architectures, the architect is the one who sees everything as an ecuation that has to be balanced (with the regular programmer being the one who messes things up and becomes the oracle to restore order to our chaotic world, bringing peace between humans and machines with a great sacrifice from the one).

Silly references aside, software design is much like designing a building (thus the comparison between software architects and traditional architects, you have to design a nifty, flexible, solid structure that has the capability to hold things up, otherwise the whole project may fall grotesquely.

This is everything for now, stay tuned.

Wololo.

Moon Machines

Hello everyone, as the title of this entry suggests I will talk about the machines and the engineers that made it possible for the human to land on the moon and return back to earth successfully, as I've began to recommend music for an easier reading of this entry, For this entry I have a special song.
The band is Public Service Broadcasting, the song: Go!
What is great about this song is that it used original recordings from the astronauts and mission control on the Apolo 11, the mission that landed on the moon, the song makes you feel like you're one of the astronauts just about to land on the moon.

Enjoy.

The video talks about the engineers that made possible the moon landing on 1969, after JFK said they would land on the moon before the end of the decade and suddenly the research facilites had a huge pressure on really doing it.

First was the Guidance Computer, just after an experiment from the MIT flew a plane on autopilot 3,000 miles the MIT was selected as the institution to develop the Apollo Guidance Computer, as the requirements weren't defined yet, the project had many problems, everyone of them was overcomed by the brilliance of every engineer working religiously on making possible this great event in human history.

While the guidance computer was being developed with many setbacks, other engineers worked on deciding whether the guidance system should be the primary guidance system or just an aid, or on what medium should the computer be programmed, the ultimately chose a medium based on hair so the software should occupy less space.

I've learned from the video that when a government invests on research projects like this a lot of inventions are made that change the way engineering is done forever.

From CAT scanners (Cancer detecting technology),  smoke detectors, water filters and more machines that we now use were invented due to the Apollo 11.
If you want to read more about it, head over to this post: http://www.telegraph.co.uk/news/science/space/5893387/Apollo-11-moon-landing-top-15-Nasa-inventions.html

About me

Hello.

In this blog I will talk about my experience while taking the course "Software Design and Architecture".

Let me introduce myself first, my name is Kevin Islas, I am a student at the Tecnológico de Monterrey studying something like computer systems engineering (although I think deep down it is most similar to Software Engineering, the name of the engineering in spanish is "Ingeniería en sistemas computacionales", but some things always get lost in translation (ironically, the spanish translation of the name of that same movie is "perdidos en Tokio") so, I guess I have a point on things being more than what the language states about them.

At this point you may be wondering how the above statement relates in any way to software design and architecture, but don't worry, I will explain it just now.

Even though programming languages are different to natural languages by being structured, carefully designed (most of them, except Lua (inside joke and nested parenthesis that only a Lisp guru would understand)) and strict in a way that statements can be understood in any context by a set of rules that are strictly defined (short story, in a natural language a concept like soft depends on the context and many other things, and in a programming language (I think they're actually called logical languages, like math) things have a meaning that is defined by a set of rules, like soft being defined as a property of a previously defined object which property is less than 5 on a previously defined scale of softness, you get the idea.

As I was saying, even in logical languages, where things are defined by a combination of statements which meaning is strictly defined, the logical structure that defines those things can variate, two programmers that can make the same thing with different logical structures, where some logical structure performs better on some scenarios and worse on others (even randomsort can be more efficient that bubblesort, in some cases).

As programming languages were designed, some favoured some aspects and others performed better on other aspects, that is because of the logical structure that was used to define those languages (and as a lua programmer that doesn't like lua, I have to admit it has its benefits).

So, knowing that languages have strengths and weaknesses (every aspect in software design can be seen as a tradeoff), when trying to build software, an experienced programmer would try to use the language that benefits the most out of the tradeoffs, or at least, use the logical structures learned by using other languages to enhance the programming language used, knowing what thing can get "lost in translation" in that process.

So, by learning software design and architecture I expect to enhance my knowledge as a programmer to benefit the most out of almost every programming problem (then, as a good programmer I expect to forget all those rules and live by what works the best).

As I have talked about my hobbies in other blogs, here I will expand what I've previously said:
I almost decided to study medicine but then I've realized that even though I loved medicine it would be best for me to study something IT related, maybe someday when I get the mid-life crisis I will get the urge for living the dream and work at something IT-medicine related.

Another thing I like is psicology, so when I have some spare time I read anything I find about medicine/psicology, partly because I find it fun, but mostly because sometimes I need to get my head out of programming to later come back with a fresher mind to solve a problem.

Wololo.