No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The truth is, words like “generic”, “general”, and “flexible” are pretty loaded words. Like the words “architect”, and “agile”, these words have different meaning to different people and unfortunately are very often misused.

The word generic is also a very absolute term. So absolute, that it actually never makes sense to use in terms of software, without a relative operator like ‘more’ or ‘less’ to describe the scale of flexibility. To say that a solution is generic is a fallacy because there is no way to assert whether a solution is generic or not. Generic implies a maximum level of abstraction. In absolute terms, this is not achievable. Does the solution cut my grass? Surely it’s not generic then.

I think in many cases the words are used flippantly in work cultures that don’t encourage innovation and evolutionary design. In cultures where software is largely defined up front and defined to satisfy requirements that are not well known or in some cases not known at all, design meetings will be driven by excessive, risk-adverse, use of this language. In work-cultures where software is not largely defined up front, or in worse cases not defined up front at all, the same thing can happen for different reasons. In this case, developers feel like they never have an opportunity to develop great solutions because they are forever putting out fires due to lack of planning. For them, use of these words is almost like a defense mechanism, and they come out of their mouth before they’ve even thought about it. They tend to overcompensate in an effort to manage delivery expectations.

I believe both cases are driven by good intentions. As developers, we like to abstract. Doing so, can remove complexity, and in many cases add heaps of value. In some cases though, it can work against us. If the solution does cut my grass then it’s possible that it isn’t doing what is supposed to do very well. The problem is when we start to look at abstraction as a silver bullet. We must remember that like “architecture” and “agile”, abstraction is a tool. Not unlike the tools we build, it isn’t the only one in the toolbox.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

http://www.infoq.com/presentations/agilists-and-architects

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A colleague said something about operating in isolated environments so that one skill-set does not influence another skill-set. He was referring specifically to analysts not having access to development resources so that the requirements gathered from the client are true and pure and not tainted by technology. It may explain why I’ve come across so much resistance in past experiences to open and collaborative environments, although I’m sure there were also those who were just reluctant to the general concept of transparency (for other obvious reasons).

While this particular point was interesting, and I must agree that it is always a challenge gathering requirements without proposing solutions, I still think there is too much to be lost by adopting a throw-it-over-the-wall-mentality.

I’ve spoke before about the importance of transparency and I don’t think working in silos is conducive to successfully delivering quality software. First of all we end up with specialists instead of generalists. Specialists are great for some tasks (typically for review and training (especially in niche areas like UX)), but generalists are what we need in software development teams. Analysts need to understand and appreciate the complexities of the software they are using as do the business/consultants/clients. The scale will vary from one end of the spectrum to the other, but the closer we can always keep everyone together, the much better the outcome. Developers must also be close to the business to appreciate and understand their pains. The only way that all of this can take place is if we stop throwing things over the wall and start talking, start working collaboratively, start sharing ideas and visions.

One of the first things you will notice if you are in a throw-it-over-the-wall type of environment is an emphasis on contracts or agreements. When the team A lead is telling the team B lead that the most important part of the design is the interface between team A’s component and team B’s component you are in trouble. The fact that team A wants to know nothing about the design of team B’s component is a sign of silos forming.

More subtly, the contract or agreement will be between a development team and another team. The outputs of one team serve as inputs for the other team. It makes sense that developed source code goes through a quality assurance cycle performed by another team for example. But, when the tester starts to require that the software be packaged in such a way that they would never need to ask a developer a question, things have gotten out of hand. Ideally, the tester would be working along side the developer, developing the test cases at the same time or before the developer.

The other problem with throwing things over the wall is that it just takes too long. People start to hold on to things because they are scared to throw it over and have it thrown back (especially if it’s not thrown back soon enough to do anything about it). This is a bad spot to be in, and will take some time to fix. People in these environments are generally very defensive and self-serving. People need to get used of working together as a team with collective ownership of all software artifacts.

It does seem like pretty basic stuff, but the truth is it requires a lot of discipline to support this type of transparency and teamwork. We all have tendencies to just do the work ourselves and not collaborate because we think it will be easier, but there are a wealth of tools / ideas for making collaboration easier and, in some cases, making it something we can’t hide from. Things like open work spaces, on-site development, scrum walls, etc are all good examples.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I particularly agree with Max’s idea that if you ‘Make your case, and show the business value, the majority of the time you will get that signature for the refactor’.

I always hear developers blaming management for a lack of time to refactor, but in my experience management is not the problem. Half the time management doesn’t even know they’re in the red. Also, they are generally thrilled to hear about how refactoring can better facilitate rapid delivery and how it’s actually a time-saver rather than a time-expenditure, if folded into the every-day development process.

In the past, I have taken the effort to consider how badly an issue is affecting development productivity, considered the effort required to fix the problem, and where relevant brought the argument forward not only to project managers, but in some cases directly to business facing consultants or clients themselves. As software professionals is it our job to make recommendations and consider trade-offs, etc. How can we say we have integrity otherwise? If we can justify the refactor, it is our job to pitch it accordingly.

This type of thinking needs to become ingrained in our day-to-day work. Seeking improvement in our software, process, and skill sets are an absolute must if we want to continue adding value in our field. Blaming management alone for technical debt is not acceptable.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Both are required for different reasons, but both are required in almost every context.

Top-down design is very valuable because it allows us to look at systems with a birds-eye view. This birds-eye view is important for evaluating whether a solution or part of a solution is fit-for-purpose. Solutions that are fit-for-purpose satisfy all of the known requirements for the system, but may also satisfy unknown and predicted requirements. The amount of top-down design subscribed to can be a slippery slope. Predicting requirements before they are known can allow us to build flexibility in early, reducing development efforts later, but building systems for requirements that may never exist does not maximize value.

Bottom-up design is very valuable because it emphasizes modular, re-usable components. Stacking modules on top of modules in layers or piecing modules together in an SOA fashion provides more flexibility because it reduces the need or desire to ‘re-invent the wheel’. Most importantly though, bottom up design forces us to think about the details, and we all know ‘the devil is in the details’. Too much bottom-up design though, can also result in wasted efforts. If modules at the bottom are being designed that aren’t fit-for-purpose, they will either remain unused (maintenance nightmare) or will need to be removed or altered.

It is together in unison, that these two approaches provide us with with the spectrum of analysis required to a) ensure a design is fit-for-purpose, and b) reduce risk and maximize re-use by considering the details of low-level modules.

Practicing these two types of approaches in unison requires a very iterative approach, not just in the software development life cycle (SDLC) as a whole, but even within a particular design phase (which may only be one task in a development iteration).

I usually start with top-down design, considering the requirements and coming up with high-level object models. Not taking this to far, and realizing my ROI, I quickly drill down to the details. This requires a great deal of prototyping and proof-of-concept work, generally resulting in throw-away software, but always resulting in a much better understanding of the problem. At this point, I will step back and review my high-level design. Undoubtedly, I will find it’s not sufficient because initially it is impossible not to gloss over important details that WILL impact the design. Having a better understanding of those details from the proof-of-concept work, I can then begin to polish my high-level design. Typically though, I need to revisit the details in order to validate the high-level design. Once this back and forth process is no longer adding enough value, the work moves through to development. Meanwhile, these mini-design iterations are happening as part of each iteration in the SDLC, so the design changes based on findings during development, and so on and so forth.

Design must be evolutionary, otherwise it can’t improve, and software that doesn’t improve over time will not add value. There are very few contexts that justify the need to design systems in a strictly top-down, up-front (waterfall) approach, and many of the traditional style development groups are incorporating bottom-up thinking and iterative approaches to their designs now as well.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Top 100 Best Software Engineering Books, Ever

Top 100 Blogs for Development Managers (Q3 2008)

They very closely align with my interests and I believe the lists to be quite credible. The authors are, in my opinion, the brightest thinkers in the software industry at the moment.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Our customers don’t need to know much about software development in order to help us develop software that adds a ton of value. A close relationship with them allows us to ‘feel their pains’ and let their knowledge drive the delivery process. It also puts some of the owness back on them. Our customers need to ‘feel our pains’ as well. You would be surprised at how helpful they can be when they become more intimately involved with the actual software.

Of course our customers will not have all of the information they need to make great project decisions on their own. As consultants, it is our job to present the relevant information, and make recommendations. As well, we mustn’t be afraid to challenge decisions made by our customers. Always consider, “If that is the answer, what is the question”. Only when communication channels are opened up like this do we start to collectively make really good decisions that ADD VALUE. Our customers must be made aware of these benefits, and only then will they start to view us as trusted advisers, strengthening the cycle further.

In the end, this back and forth collaboration leads to a shared vision, and a more well-rounded team commitment that makes project success much more obtainable.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

That said, there are many professionals in our industry that are more than happy to not be developing. They may have a passion for Support or for Testing, or for coordinating Builds and Releases, or for Business Analysis. Yet, they will be tasked with development efforts just like every one else on the team. So while all of the developers on the team are juggling all areas of software development, there are actually specialists on the team that would be thrilled to focus their energy on one task consistently.

I’m not saying the roles should be so well defined as to disallow any overlap because there will be those who like to move around (like myself). I’m just saying that it is important to recognize specific skills and desires on the team, and embrace them in a way that increases project velocity whenever possible.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Unfortunately, this creates a big gap between the end-user’s understanding of their software and the actual implementation of their software. It’s like the old trick where you whisper something into another person’s ear and then have that process repeated amongst 10 other people. When the last person is asked to repeat what they’ve heard, it is always different than what was put forth in the beginning. This is what happens when customers ask us for something and we try and build it on our own, without any checkpoints. The software becomes less aligned with what was requested, but further more, the end-user is distanced from its implementation.

Agile thinkers approach this in a much more effective and efficient way. They bring end-users as close to the implementation as possible so that the gap between their business and the technology driving their business is reduced significantly. They make transparency the focus in every process. I mentioned in my post about the Agile 2007 conference that there are a number of ways to facilitate transparency (I called them visibility facilitators) on any project, including open work-spaces, project collaboration / management / dashboard tools, and regular feedback. Conducting retrospectives and collecting metrics and velocities are also valuable tools for facilitating transparency. The obvious facilitator, not mentioned in that list, is on-site development with dedicated end-users staffed specifically for the project.

It’s not enough to have transparency in the process though. We need to take it one step further and develop transparent software. This has always been a battle for me, because I am so passionate about software usability, and I understand that rich UIs need to be able to hide system complexities in order to enhance the end-user experience. What I don’t like about that type of thinking is that it often results in systems with unnecessary complexities. While every problem has inherent complexities, we have to do our best as software developers to avoid introducing additional, unnecessary complexities. Often, these unnecessary complexities are masked by very non-transparent UIs. I live by the words ‘No Magic’, because I believe that a good UI should be communicating with the end-user, the same way that it will be communicating with the system. For example, if I click a button that says ‘Calculate Reconciliation’, I would expect that the interface is going to tell the system to ‘Calculate Reconciliation’, NOT ‘Calculate Reconciliation AND Send Various Emails AND Update Invoices, AND …’. While the extra steps taken may be useful, I didn’t really ask for it, so I start to feel like there is a bunch of magic going on behind the scenes that I don’t know about. I hate magic! My thoughts are that interface developers should start with the most transparent interface possible. Try to align the language on the screen as much as possible with the language used in the system (and visa versa). Try to expose function points or system intentions with obvious controls. Only when everything is fully functional should you start making UI tweaks that depart from back-end design. Lastly, I think it is important to push changes in understanding vertically through every layer of the system as often as possible. If this week this business are calling the Calculate Reconciliation function Reconcile Books, make that transparent and push that language through every layer of the system. Likewise, if a data relationship changes from 1-1 to 1-many in the back-end, make that transparent and push that relationship through every layer of the system so that if possible, it is obvious even in the interface.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.